[
https://issues.apache.org/jira/browse/PHOENIX-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lokesh Khurana updated PHOENIX-7908:
------------------------------------
Summary: Snapshot-anchored cutover/partial-pass reads + CUTOVER_IN_PROGRESS
CAS (was: Snapshot-anchored cutover/partial-pass reads + CUTOVER_IN_PROGRESS
CA)
> Snapshot-anchored cutover/partial-pass reads + CUTOVER_IN_PROGRESS CAS
> ----------------------------------------------------------------------
>
> Key: PHOENIX-7908
> URL: https://issues.apache.org/jira/browse/PHOENIX-7908
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Lokesh Khurana
> Priority: Major
>
> {{Transform.doCutover}} and
> {{TransformTool.populateTransformToolAttributesAndValidate }}both look up the
> LIVE PTable via {{{}connection.getTable(logicalName){}}}. After the first
> cutover commit (or after a JVM crash mid-cutover, with retry), the live
> PTable already reflects post-cutover state. The diff comes back empty;
> per-view loop UPSERTs propagate stale values; tables and views are stuck in a
> permanent half-cutover.
> The same root cause surfaces in {{TransformTool}} partial-pass — post-cutover
> partial-pass operates on the wrong-direction maintainer (decode-NEW
> encode-NEW), producing a silent no-op or cross-schema corruption.
>
> *Decision:*
> # Snapshot-anchored diff: deserialize {{pOldTable}} from
> {{systemTransformRecord.getOldMetadata()}} (the immutable byte array written
> at addTransform time) instead of looking up the live PTable. {{pNewTable
> }}continues to be a live read.
> # {{CUTOVER_IN_PROGRESS}} state via SYSCAT-timestamp CAS:
> at-most-one-monitor serializes cutover work. Crash-recovery is safe because
> the snapshot anchor makes re-run idempotent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
