You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
149616: changefeedccl: protect lagging tables with its own timestamp r=andyyang890 a=aerfrei
Before this change, changefeeds watching multiple tables
would protect all watched tables and system tables with a
single protected timestamp (pts) record. All tables would
be protected back to the highwater for the changefeed.
In the event where one table lags behind the others, this
would result in preventing more garbage collection than
needed for many tables. This would become more of an issue
when we introduce DB-level feeds because they will be
implemented with multi-table feeds.
We now protect lagging tables separately. We use per table
highwaters to identify tables who are lagging behing the
most advanced table by more than the new
changefeed.protect_timestamp_bucketing_interval cluster
setting. All tables at least that far behind will be protected
by their own pts record.
Epic: CRDB-1421Fixes: #147785
Release note (performance): Multi-table changefeeds will protect
each lagging user table from garbage collection with its own record.
This will improve performance of multi-table changefeeds including
upcoming db-level changefeeds by allowing more garbage collection.
152190: contention: periodically log resolved contention events r=alyshanjahani-crl a=alyshanjahani-crl
This commit adds logging to the flushAndResolve method in the contention event
store. This method is called periodically at an interval defined by the
(non-public) cluster setting sql.contention.event_store.resolution_interval.
By logging aggregated contention event information, users now have the ability
to find which waiting statements/txns are experiencing high contention through
logs (previously this was only available via insights or SQL activity).
Additionally, this aggregated event information contains the blocking txn and
contended key - information that was previously only available via querying
crdb_internal.transaction_contention_events.
The logs are aggregated by a composite identifier of
(waiting stmt, waiting txn, blocking txn, key), and the total contention time
observed for that combination. They are structured logs. For example:
```
{"Timestamp":1756224167482848000,"EventType":"aggregated_contention_info",
"WaitingStmtFingerprintId":"\\x000000000000007b",
"WaitingTxnFingerprintId":"\\x00000000000001c8",
"BlockingTxnFingerprintId":"\\x0000000000000315",
"ContendedKey":"test-key-1","Duration":300000000}
```
Since this information is available via logs, it provides a solution for users
who desire more persistence of contention event information.
Part of: https://cockroachlabs.atlassian.net/browse/CRDB-53592
Release note (ops change): Adds logging of contention events.
Co-authored-by: Aerin Freilich <[email protected]>
Co-authored-by: Alyshan Jahani <[email protected]>
0 commit comments