[ https://issues.apache.org/jira/browse/PHOENIX-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155722#comment-16155722 ]
Vincent Poon edited comment on PHOENIX-3953 at 9/6/17 5:17 PM: --------------------------------------------------------------- [~jamestaylor] Is there a way for us to signal that this happened, perhaps by setting the indexDisableTimestamp to a special negative value? At a minimum, I think we should add a log line to indicate this. Otherwise from an operator perspective, we would see a disabled index and have to triage why the rebuilder didn't fix it. Perhaps a new index state would make it even clearer was (Author: vincentpoon): [~jamestaylor] Is there a way for us to signal that this happened, perhaps by setting the indexDisableTimestamp to a special negative value? At a minimum, I think we should add a log line to indicate this. Otherwise from an operator perspective, we would see a disabled index and have to triage why the rebuilder didn't fix it. > 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)