[
https://issues.apache.org/jira/browse/PHOENIX-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154801#comment-16154801
]
Lars Hofhansl commented on PHOENIX-3953:
----------------------------------------
Cool. Thanks for explaining, James.
I'd advise against letting the compaction fail. If the compaction is time based
we might only retry at the next interval (7 days later by defaul)
Some thoughts/comments:
* As a general comment... Can we add more comments to the code? :) This is a
pretty tricky thing, and the code does not explain at all why we're doing this.
(This is something systemic to Phoenix)
* Also - apologies if this should be clear from the code - what happens when
the index is marked such that it should remain active while it is being
rebuild? In that case, should we still mark it is active?
* Lastly, what are the timeout settings? Same as for index updates? (It would
be pretty fatal if we hang the compaction for many minutes.)
> 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_addendum1.patch, PHOENIX-3953.patch,
> PHOENIX-3953_v2.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)
