phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3953) Clear INDEX_DISABLED_TIMESTAMP and disable index on compaction
Date Wed, 06 Sep 2017 04:37:01 GMT


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:
>             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

View raw message