phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kadir OZDEMIR (JIRA)" <>
Subject [jira] [Updated] (PHOENIX-2582) Prevent need of catch up query when creating non transactional index
Date Thu, 16 May 2019 05:06:00 GMT


Kadir OZDEMIR updated PHOENIX-2582:
    Comment: was deleted

(was: [~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:
>             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

View raw message