[
https://issues.apache.org/jira/browse/PHOENIX-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: 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)
