-
Notifications
You must be signed in to change notification settings - Fork 4.1k
server: information returned by SpanStats should be authoritative #103957
Copy link
Copy link
Closed
Labels
C-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Description
The work done to improve server.SpanStats in #96223 and #101378 uses instances of kvcoord.RangeIterator so that each node may collect range descriptors relevant to the request span(s).
The problem is that kvcoord.RangeIterator uses kvcoord.DistSender's caching infrastructure to find these descriptors, and the state of the cache on each node may be different at any given time. Although the caches will eventually be consistent, the risk of inconsistency is not acceptable for this endpoint. This has come to light in #103128 where server.SpanStats has become a dependency of SHOW RANGES, which must be authoritative.
Some additional points from @knz:
- the “new” code for the stats-for-span function is deeply embedded in the obs API server, which is architecturally unsound since the functionality is a pure KV function and should be usable from SQL without interfacing with the API server at all.
- we want to have a version of this code that is guaranteed to operate on a consistent view of the entire span (i.e. not a mix of cached data for part of the span, and uncached for another part)
- we want the API to be able to reuse an existing client.Txn object (instead of synthetisizing its own)
This issue revisits CRDB-22711 and CRDB-17463
Jira issue: CRDB-28270
Epic: CRDB-24928
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
C-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)