[
https://issues.apache.org/jira/browse/PHOENIX-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131445#comment-16131445
]
Thomas D'Silva commented on PHOENIX-4092:
-----------------------------------------
[~apurtell] had some suggestions related to this in an email conversation
https://issues.apache.org/jira/browse/PHOENIX-2582?focusedCommentId=15113226&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15113226
> Ensure index and table remains in sync when the table is mutating during
> index build
> ------------------------------------------------------------------------------------
>
> Key: PHOENIX-4092
> URL: https://issues.apache.org/jira/browse/PHOENIX-4092
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> There's code in MetaDataClient.buildIndex() which runs a "catchup" query
> after the initial index population finishes to find any rows for inflight
> writes made while the population is taking place. This is meant to handle the
> case in which one client runs an UPSERT SELECT while another issues a CREATE
> INDEX. Since the UPSERT SELECT began before the CREATE INDEX, index
> maintenance will not be performed. The catchup query is meant to handle this
> scenario, though it makes an assumption that it can wait long enough for any
> such DML operations to complete prior to running the catchup query. Instead,
> we should have a mechanism to wait until all inflight DML operations on a
> table are complete.
> Note also that if an index is built asynchronously, there's no catchup query
> run at all.
> We should increase the testing we have around this scenario and deal with
> these corner cases. For one such test, see
> ImmutableIndexIT.testCreateIndexDuringUpsertSelect().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
