lokiore opened a new pull request, #2611: URL: https://github.com/apache/phoenix/pull/2611
### What changes were proposed in this pull request? This flips the client default `DEFAULT_SERVER_SIDE_IMMUTABLE_INDEXES_ENABLED` from `false` to `true`. With the flag enabled, immutable, global, non-transactional secondary indexes are maintained server-side by `IndexRegionObserver` (added in PHOENIX-7426) rather than by the client. The client no longer generates index mutations for these tables; it ships the serialized `IndexMaintainer` and lets the region server build the index updates exactly once. To keep the flip safe, immutable data tables that declare a `ROW_TIMESTAMP` column continue to be maintained client-side regardless of the flag. The decision is centralized in a new helper, `IndexUtil.isServerSideImmutableIndexMaintenanceEnabled(...)`, and applied at every data-table gate that reads the flag: - `IndexUtil.getClientMaintainedIndexes` - `IndexMaintainer.maintainedLocalOrGlobalIndexesWithoutMatchingStorageScheme` (the `INDEX_UUID` gate) - `MutationState.filterIndexCheckerMutations` - `DeleteCompiler.isMaintainedOnClient` (signature extended to take the data table so the guard resolves `ROW_TIMESTAMP` against the data table, not a projected or index table) - `IndexMetaDataCacheClient.setMetaDataOnMutations` (the send-metadata gate) Routing all gates through the same helper keeps the client and server in agreement on which side maintains a given table; a disagreement would cause a `ROW_TIMESTAMP` table to be maintained on both sides. ### Why are the changes needed? PHOENIX-7426 added server-side maintenance of immutable-table indexes behind a flag that defaulted to off. Enabling it by default removes per-batch client index-mutation generation for immutable tables and lets `IndexRegionObserver` (the default index path for years, `DEFAULT_INDEX_REGION_OBSERVER_ENABLED=true`) build the index 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, overwriting the user-supplied `ROW_TIMESTAMP` value. `ROW_TIMESTAMP` range predicates push an HBase scan `TimeRange`, so re-stamped cells fall outside it and rows are silently dropped on range reads (SCN-based visibility breaks for the same reason). This is the same hazard behind `CANNOT_CREATE_INDEX_ON_MUTABLE_TABLE_WITH_ROWTIMESTAMP`, which already forbids the mutable variant; the immutable variant was safe only because it was client-maintained. ### Does this PR introduce _any_ user-facing change? Yes. Immutable, global, non-transactional secondary indexes are now maintained server-side by default (previously client-side unless the flag was set explicitly). Upgrade notes: - Upgrade region servers before clients. Server-side maintenance rides the generic `IndexRegionObserver` path, which is enabled by default; on a default cluster a new client talking to an already-upgraded (or default-configured) server loses no index data. - Silent index-data loss is only reachable on the deprecated legacy-Indexer configuration (`phoenix.index.region.observer.enabled=false`). Clusters still on that configuration must move off it before adopting this default. - Immutable tables with a `ROW_TIMESTAMP` column are unaffected — they remain client-maintained. - The previous behavior can be restored by setting `phoenix.index.server.side.immutable.indexes.enabled=false`. ### How was this patch tested? - `RowTimestampIT` — regression lock; asserts raw-scan cell timestamps equal the user `ROW_TIMESTAMP` on both data and index tables for the immutable case. Passes with the guard. - `ServerSideImmutableIndexIT` and `ClientSideImmutableIndexIT` — pass. - `PhoenixMetricsIT`, `PhoenixLoggingMetricsIT`, and `PhoenixTableLevelMetricsIT#testMetricsWithIndexUsage` — pass; the flag is pinned off at the driver level for the assertions that account for client-side index mutations. ### 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]
