[jira] [Commented] (PHOENIX-2582) Prevent need of catch up query when creating non transactional index

["Kadir OZDEMIR (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840853#comment-16840853 ] 

Kadir OZDEMIR commented on PHOENIX-2582:
----------------------------------------

[~giskender] just pointed out this Jira to me. [~tdsilva], [~vincentpoon], [~lhofhansl], [~apurtell], as you may know, she is going to implement the remaining changes for immutable indexes for the new index design (PHOENIX-5156). Immutable indexes are currently implemented on the client side. We were planning to follow this decision for the new design too. Given this problem, given that mutable indexes are implemented on the server side, and given that immutable indexes do not require any row locking (for read consistency and concurrent updates) and therefore do not pose deadlock issues, should not we implement them on the server side too to address the issue of this Jira? Implementing them on the server side will be much easier. 

> Prevent need of catch up query when creating non transactional index
> --------------------------------------------------------------------
>
>                 Key: PHOENIX-2582
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2582
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Thomas D'Silva
>            Priority: Major
>
> If we create an index while we are upserting rows to the table its possible we can miss writing corresponding rows to the index table. 
> If a region server is writing a batch of rows and we create an index just before the batch is written we will miss writing that batch to the index table. This is because we run the inital UPSERT SELECT to populate the index with an SCN that we get from the server which will be before the timestamp the batch of rows is written. 
> We need to figure out if there is a way to determine that are pending batches have been written before running the UPSERT SELECT to do the initial index population.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)