[
https://issues.apache.org/jira/browse/PHOENIX-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell updated PHOENIX-8046:
-----------------------------------------
Summary: ALTER INDEX ... CONSISTENCY can desynchronize the metadata cache
(was: ALTER INDEX ... CONSISTENCY can desynchronize client metadata caches)
> ALTER INDEX ... CONSISTENCY can desynchronize the metadata cache
> ----------------------------------------------------------------
>
> Key: PHOENIX-8046
> URL: https://issues.apache.org/jira/browse/PHOENIX-8046
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 5.3.2
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Major
> Fix For: 5.4.0, 5.3.3
>
>
> Modifying an index's consistency model via {{ALTER INDEX ... CONSISTENCY}}
> can silently desynchronize client metadata caches from the underlying schema.
> A client connection can cache the parent data table without the altered index
> attached. Subsequent write paths fail to maintain the index, and query
> planners ignore it. Because the index metadata remains marked as
> {{{}ACTIVE{}}}, direct reads against it yield missing or stale data.
> Updating consistency modifies only the index header row, leaving the parent
> table's {{PTable}} and timestamp unchanged. Immediately following the write,
> the client invalidates its local cache by invoking
> {{PMetaDataImpl.removeTable}} with the parent table's name and
> {{{}LATEST_TIMESTAMP{}}}. Rather than dropping the parent entry, the client
> cache attempts to rebuild the parent definition in place with the index
> stripped out, preserving the original parent timestamp. Because this
> timestamp still matches the unmodified server record, subsequent schema
> resolutions conclude the client's cached parent is current. The client
> remains pinned to an incomplete table definition. Explicitly resolving the
> index by name could temporarily reattach it. However, a concurrent lookup of
> the parent table would overwrite that repair with the earlier incorrect
> snapshot.
> To guarantee cache coherence, the invalidation model requires two coordinated
> changes:
> * *Client Cache Invalidation:* When {{PMetaDataImpl.removeTable}} is invoked
> with {{{}LATEST_TIMESTAMP{}}}, it must evict the parent table entry entirely.
> Forcing an eviction ensures the next schema resolution refetches the complete
> parent definition from the server, preventing stale in-memory snapshots from
> perpetuating partial states. When an explicit timestamp is supplied, the
> existing selective removal behavior is preserved.
> * *Server Cache Coherence:* The ALTER path must proactively purge the parent
> data table from the server side metadata cache. Because the server caches
> data tables alongside their associated index descriptors, evicting the parent
> prevents the server from serving stale descriptors to subsequent client
> lookups.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
