[
https://issues.apache.org/jira/browse/PHOENIX-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16422881#comment-16422881
]
Vincent Poon commented on PHOENIX-4682:
---------------------------------------
Thanks for the reviews. [~apurtell] There are two reasons we have precompact
hooks. One is for stats, the other is for secondary indexes - if the index is
disabled we don't want to compact the data table because the index will get out
of sync if the rebuild is run without the deleted cells.
It's arguable whether we should bubble up the IOException to abort the
compaction or not. I'm not that familiar with stats but for indexes, it's a
correctness issue so I'll take your suggestion and throw up the IOException.
[~gjacoby] There doesn't seem to be an issue with System.Catalog - since it's a
bonafide Phoenix table, my test case is able to compact it with the coprocessor
logic. Also I think what Andrew was saying was that we can/should throw
IOExceptions (which abort the compaction), just not other types of exceptions
(which abort the RS).
> UngroupedAggregateRegionObserver preCompactScannerOpen hook should not throw
> exceptions
> ---------------------------------------------------------------------------------------
>
> Key: PHOENIX-4682
> URL: https://issues.apache.org/jira/browse/PHOENIX-4682
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.13.0
> Reporter: Vincent Poon
> Assignee: Vincent Poon
> Priority: Major
> Attachments: PHOENIX-4682.master.v1.patch
>
>
> TableNotFoundException in the preCompactScannerOpen hook can lead to RS abort.
> Some tables might have the phoenix coprocessor loaded but not be actual
> Phoenix tables (i.e. have a row in SYSTEM.CATALOG). We should ignore these
> Exceptions instead of throwing them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
