[
https://issues.apache.org/jira/browse/PHOENIX-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell updated PHOENIX-7996:
-----------------------------------------
Fix Version/s: PHOENIX-7562-feature
5.4.0
> Correctly maintain immutable global indexes on the server side for partial
> upserts
> -----------------------------------------------------------------------------------
>
> Key: PHOENIX-7996
> URL: https://issues.apache.org/jira/browse/PHOENIX-7996
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Lokesh Khurana
> Assignee: Lokesh Khurana
> Priority: Major
> Fix For: PHOENIX-7562-feature, 5.4.0
>
>
> PHOENIX-7426 added server-side maintenance of immutable-table indexes behind
> phoenix.server.side.immutable.indexes.enabled (default off). This hardens that
> opt-in path and closes two correctness gaps. The default stays off; flipping
> it
> on is a separate follow-up.
> 1. Partial-upsert read-back: IndexRegionObserver skips the read-back for
> immutable
> batches, so a partial upsert omitting an indexed/covered/index-WHERE column
> builds the index entry from the partial mutation alone — dropping a covered
> column, or writing a spurious null-keyed uncovered entry. Now forces a
> read-back only when an enabled mutation omits one of the index's on-disk
> columns; full-row upserts keep the fast path.
> 2. Uncovered global immutable indexes with a matching storage scheme were
> maintained by nobody: the serialize filter matched GLOBAL only. It now
> matches
> IndexUtil.isGlobalIndex (GLOBAL + UNCOVERED_GLOBAL).
> ROW_TIMESTAMP carve-out: immutable tables with a ROW_TIMESTAMP column stay
> client-maintained regardless of the flag (server-side re-stamping would break
> ROW_TIMESTAMP range reads). The maintenance-side decision is centralized in
> IndexUtil.isServerSideImmutableIndexMaintenanceEnabled(...) so client and
> server
> never disagree.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
