[
https://issues.apache.org/jira/browse/PHOENIX-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034656#comment-15034656
]
James Taylor commented on PHOENIX-2446:
---------------------------------------
For one reproducible case involving transactions, 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 doesn't shed any light on the non transactional case where this is
occurring, though.
> Immutable index - Index vs base table row count does not match when index is
> created during data load
> -----------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-2446
> URL: https://issues.apache.org/jira/browse/PHOENIX-2446
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.6.0
> Reporter: Mujtaba Chohan
>
> I'll add more details later but here's the scenario that consistently
> produces wrong row count for index table vs base table for immutable async
> index.
> 1. Start data upsert
> 2. Create async index
> 3. Trigger M/R index build
> 4. Keep data upsert going in background during step 2,3 and a while after M/R
> index finishes.
> 5. End data upsert.
> Now count with index enabled vs count with hint to not use index is off by a
> large factor. Will get a cleaner repro for this issue soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
