[
https://issues.apache.org/jira/browse/PHOENIX-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556489#comment-17556489
]
ASF GitHub Bot commented on PHOENIX-6627:
-----------------------------------------
gjacoby126 commented on PR #1455:
URL: https://github.com/apache/phoenix/pull/1455#issuecomment-1160722256
Also, what will happen to user tables who upgrade from Phoenix 5.1 -> 5.2
and have the Provider set to Tephra? Would that cause the region to crash from
trying to load an enum value that doesn't exist? If so, what sort of upgrade
logic should we include? I can think of three options:
1. Switch tables to non-transactional
2. Switch tables to Omid
3. Keep the Tephra enum and just WARN or ERROR on region load that it
doesn't do anything
1 and 2 are both tricky to coordinate on a rolling restart, because the
normal upgrade logic runs when SYSTEM.CATALOG is upgraded, but the crashing
would probably come before that, when a region hosting a TEPHRA-enabled table
has its region server upgraded. But I worry that some operators would miss the
warning in their logs.
@stoty @jpisaac @kadirozde @virajjasani , curious on your opinions.
> Remove all references to Tephra from 4.x and master
> ---------------------------------------------------
>
> Key: PHOENIX-6627
> URL: https://issues.apache.org/jira/browse/PHOENIX-6627
> Project: Phoenix
> Issue Type: Sub-task
> Components: 4.x, tephra
> Reporter: Istvan Toth
> Assignee: Zsolt Gyulavari
> Priority: Major
>
> Removing tephra from the runtime is easy, as it uses the well defind
> TransactionProvider interfaces.
> Removing Tephra references from all the test cases is a much bigger task.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
