[jira] [Assigned] (PHOENIX-7907) Cutover lifecycle with PENDING_PARTIAL_PASS state, UCF-wait, and link removal at cutover commit

["Lokesh Khurana (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PHOENIX-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lokesh Khurana reassigned PHOENIX-7907:
---------------------------------------

    Assignee: Lokesh Khurana

> Cutover lifecycle with PENDING_PARTIAL_PASS state, UCF-wait, and link removal at cutover commit
> -----------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-7907
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-7907
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Lokesh Khurana
>            Assignee: Lokesh Khurana
>            Priority: Major
>
> The current cutover flow ({{{}Transform.doCutover{}}} → schedule partial-pass immediately) runs partial-pass concurrently with stale-cache dual-write traffic, allowing stranded UNVERIFIED rows. The fix introduces a new {{PENDING_PARTIAL_PASS}} status between {{PENDING_CUTOVER}} and partial-pass scheduling, where the monitor waits a UCF-derived window before transitioning forward. Link removal happens AT cutover commit (Order B), so a single cache cycle propagates both the PHYSICAL_TABLE_NAME swap and the link-removal.
> *State machine:*
>  
> {{PENDING_CUTOVER}} → {{Transform.doCutover}} (single SYSCAT commit: swap PHYSICAL_TABLE_NAME on logical row + each view, DELETE TRANSFORMING_NEW_TABLE link rows, clearCache RPC) → status flips to {{PENDING_PARTIAL_PASS}} with {{PENDING_PARTIAL_PASS_UNTIL_TS = now + max(UCF * 1.10, 30 min)}} → wall-clock until UNTIL_TS → status flips to {{PARTIAL_PASS_RUNNING}} → TransformTool partial-pass MR scans NEW for UNVERIFIED rows.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)