phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-4092) Ensure index and table remains in sync when the table is mutating during index build
Date Thu, 17 Aug 2017 17:36:00 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Taylor updated PHOENIX-4092:
----------------------------------
    Summary: Ensure index and table remains in sync when the table is mutating during index
build  (was: Ensure index and table remains in sync when the table is mutating)

> 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)

Mime
View raw message