[
https://issues.apache.org/jira/browse/PHOENIX-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036929#comment-15036929
]
James Taylor commented on PHOENIX-2478:
---------------------------------------
Even today, DML operations would be fine because these would be covered by the
standard conflict detection mechanism by virtue of the row keys conflicting for
the SYSTEM.CATALOG table. The CREATE INDEX case is different because it
involves both a DML change *and* data changes (i.e. populating the index table
rows for existing data table rows).
> Rows committed in transaction overlapping index creation are not populated
> --------------------------------------------------------------------------
>
> Key: PHOENIX-2478
> URL: https://issues.apache.org/jira/browse/PHOENIX-2478
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> For a reproducible case, see IndexIT.testCreateIndexAfterUpsertStarted() and
> the associated FIXME comments for PHOENIX-2446.
> The case that is failing is when a commit starts before an index exists, but
> commits after the index build is completed. For transactional data, this is
> problematic because the index gets a timestamp after the commit of the data
> table mutation and thus these mutations won't be seen during the commit.
> Also, when the index is being built, the data hasn't yet been committed and
> thus won't be part of the initial index build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
