[
https://issues.apache.org/jira/browse/PHOENIX-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lokesh Khurana updated PHOENIX-7996:
------------------------------------
Description:
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.
was:
PHOENIX-7426 added server-side maintenance of immutable global indexes, gated
behind the client config phoenix.server.side.immutable.indexes.enabled (default
false). When enabled, non-transactional, non-local immutable global indexes are
maintained by IndexRegionObserver on the region servers instead of being
generated on the client; because immutable rows have no prior state, the server
skips the read-before-write that mutable-index maintenance requires.
This issue flips the default to true, so immutable-index maintenance is
server-side out of the box.
> 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
>
> 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)