[
https://issues.apache.org/jira/browse/PHOENIX-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141303#comment-16141303
]
Samarth Jain commented on PHOENIX-3953:
---------------------------------------
Thanks for the patch, [~jamestaylor]. I have a couple of comments:
- With this patch, we are setting the index_disable_timestamp to 0 when the the
major compaction is running for the *index* table. I think we would need to do
the same when major compaction is running on the data table too. I am not too
sure what would happen if major compaction runs on a disabled index. It may or
may not be ok. But definitely, major compaction running on a data table when a
global mutable index on it is disabled is not good.
- I am not too sure if adding this logic to stats collection is the best
choice. In fact, I was planning on filing a JIRA where we can have a config
which controls whether we should be collecting stats for tables via major
compaction. I think it would make sense to just refactor this logic in its own
method and call it in the preCompactHook of UngroupedAggregateRegionObserver.
> Clear INDEX_DISABLED_TIMESTAMP and disable index on compaction
> --------------------------------------------------------------
>
> Key: PHOENIX-3953
> URL: https://issues.apache.org/jira/browse/PHOENIX-3953
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Labels: globalMutableSecondaryIndex
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3953.patch
>
>
> To guard against a compaction occurring (which would potentially clear delete
> markers and puts that the partial index rebuild process counts on to properly
> catch up an index with the data table), we should clear the
> INDEX_DISABLED_TIMESTAMP and mark the index as disabled. This could be done
> in the post compaction coprocessor hook. At this point, a manual rebuild of
> the index would be required.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
