lokiore opened a new pull request, #2618:
URL: https://github.com/apache/phoenix/pull/2618
### What changes were proposed in this pull request?
This targets the **Consistent Failover feature branch**
(`PHOENIX-7562-feature-new`). It brings the server-side immutable-index
correctness hardening from #2611 to this branch and **enables it by default**
(`DEFAULT_SERVER_SIDE_IMMUTABLE_INDEXES_ENABLED` flips `false` → `true`).
With the flag on, immutable, global, non-transactional secondary indexes are
maintained server-side by `IndexRegionObserver` (PHOENIX-7426) rather than by
the client: the client ships the serialized `IndexMaintainer` and the region
server builds the index updates exactly once. Immutable data tables that
declare a `ROW_TIMESTAMP` column continue to be maintained client-side
regardless of the flag.
This is the companion of #2611. #2611 lands the same hardening on `master`
**off by default** (a pure correctness fix); this PR is where the default is
turned on, on the branch that adopts server-side immutable-index maintenance.
Hardening (identical to #2611):
- The maintenance-side decision is centralized in
`IndexUtil.isServerSideImmutableIndexMaintenanceEnabled(...)` and every
data-table gate routes through it — `IndexUtil.getClientMaintainedIndexes`,
`IndexMaintainer.maintainedLocalOrGlobalIndexesWithoutMatchingStorageScheme`
(the `INDEX_UUID` gate), `MutationState.filterIndexCheckerMutations`,
`DeleteCompiler.isMaintainedOnClient` (signature extended to take the data
table so `ROW_TIMESTAMP` resolves against the data table),
`IndexMetaDataCacheClient.setMetaDataOnMutations`, and `UpsertCompiler` — so
client and server never disagree on which side maintains a table.
- **Partial-upsert read-back.** `IndexRegionObserver` skips the current-row
read-back for immutable batches; a partial upsert omitting an
indexed/covered/index-WHERE column would then build the index entry from the
partial mutation alone (dropping a covered column, or writing a spurious
null-keyed uncovered entry). The read-back gate now forces a read-back for
immutable batches carrying a covered or uncovered global index when an enabled
mutation omits one of that index's on-disk columns; full-row upserts and
single-cell tables keep the no-read-back fast path.
- **Broadened serialize filter.** The immutable server-serialize filter now
matches `IndexUtil.isGlobalIndex` (covering `GLOBAL` and `UNCOVERED_GLOBAL`),
so an uncovered global immutable index with a matching storage scheme is
maintained rather than dropped by both client and server.
### Why are the changes needed?
Enabling server-side maintenance by default on this branch removes per-batch
client index-mutation generation for immutable tables and lets
`IndexRegionObserver` (the default index path) build the updates, reducing
client-side work and mutation payload. The `ROW_TIMESTAMP` carve-out is
required for correctness: server-side maintenance re-stamps every data cell —
including the `ROW_TIMESTAMP` column — with the server batch timestamp, so
`ROW_TIMESTAMP` range predicates (which push an HBase scan `TimeRange`) would
silently drop rows on range reads. This mirrors
`CANNOT_CREATE_INDEX_ON_MUTABLE_TABLE_WITH_ROWTIMESTAMP` for the mutable
variant.
### Does this PR introduce _any_ user-facing change?
Yes, on this feature branch: immutable, global, non-transactional secondary
indexes are maintained server-side by default (previously client-side unless
the flag was set). Immutable tables with a `ROW_TIMESTAMP` column are
unaffected (client-maintained). Upgrade region servers before clients;
server-side maintenance rides the default-enabled `IndexRegionObserver` path.
The previous behavior can be restored with
`phoenix.server.side.immutable.indexes.enabled=false`.
### How was this patch tested?
Same coverage as #2611. Partial-upsert/delete coverage in
`BaseImmutableIndexIT` runs under both `ServerSideImmutableIndexIT` (flag on)
and `ClientSideImmutableIndexIT` (flag off), parameterized over storage scheme.
`GlobalIndexCheckerIT#testPartialRowUpdateForImmutable{,Uncovered}` lock the
read-back fix; the uncovered COUNT invariant is asserted only when server-side
maintenance is enabled (read from the effective flag).
`UncoveredGlobalImmutableNonTxIndexIT`/`...2IT` exercise the broadened
serialize filter. `RowTimestampIT` locks the `ROW_TIMESTAMP` carve-out. The
metrics/RPC ITs pin the flag off for assertions that account for client-side
index mutations; `IndexToolIT` reads the effective flag. Heavy immutable/index
ITs are exercised in CI.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.8)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
