Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: contention event store main tracking issue #74485

Closed
14 of 20 tasks
Azhng opened this issue Jan 6, 2022 · 0 comments
Closed
14 of 20 tasks

sql: contention event store main tracking issue #74485

Azhng opened this issue Jan 6, 2022 · 0 comments
Labels
A-sql-observability Related to observability of the SQL layer C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)

Comments

@Azhng
Copy link
Contributor

Azhng commented Jan 6, 2022

This is the meta tracking issue for the new Contention Event Registry described in the Contention Even Store RFC


In scope for 22.1

Infrastructure

Performance

Interface


Post 22.1

Data Persistence

  • System table for persisting contention event
  • Periodic flush process
  • Periodic cleanup job for deleting old data
  • Virtual table that exposes combined in-memory and persisted contention events (Require Data Persistence)

UX

  • New Contention Tab under SQL Activity Page

Optimization:

  • Self Throttling (possibly using low pass filter option)
  • Implement ConcurrentWriteBuffer Sharing between connExecutors
  • Resolver outbound RPC rate limiter
@Azhng Azhng added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) A-sql-observability Related to observability of the SQL layer T-sql-observability labels Jan 6, 2022
@Azhng Azhng added this to Triage in Cluster Observability via automation Jan 6, 2022
@Azhng Azhng changed the title sql: contention event store main tracking issue. sql: contention event store main tracking issue Jan 6, 2022
@kevin-v-ngo kevin-v-ngo moved this from Triage to 22.1 in Cluster Observability Jan 10, 2022
Azhng added a commit to Azhng/cockroach that referenced this issue Jan 11, 2022
Previously, the transaction ID cache recorded the mapping from
transaction ID to transaction fingerprint ID once the transaction
finished executing. This introduced a problem where, when we queried the
transaction ID cache with a transaction ID, and we were not able to
distinguish between the case where transaction ID entry was being
evicted, or the transaction with that ID was still executing.

This commit addresses this problem by immediately starting a write
operation to write a provisional transaction fingerprint ID into
transaction ID cache once the transaction ID for a transaction is
determined. This is then followed up with additional write operation
once the transaction finishes execution where the transaction
fingerprint ID is then determined. Since transaction ID Cache always
returns the most-recent written value for a given key, the the
provisional transaction fingerprint ID will not be returned once the
actual transaction fingerprint ID is written.

Related cockroachdb#74485.

Release note: None
Azhng added a commit to Azhng/cockroach that referenced this issue Jan 19, 2022
Previously, the transaction ID cache recorded the mapping from
transaction ID to transaction fingerprint ID once the transaction
finished executing. This introduced a problem where, when we queried the
transaction ID cache with a transaction ID, and we were not able to
distinguish between the case where transaction ID entry was being
evicted, or the transaction with that ID was still executing.

This commit addresses this problem by immediately starting a write
operation to write a provisional transaction fingerprint ID into
transaction ID cache once the transaction ID for a transaction is
determined. This is then followed up with additional write operation
once the transaction finishes execution where the transaction
fingerprint ID is then determined. Since transaction ID Cache always
returns the most-recent written value for a given key, the the
provisional transaction fingerprint ID will not be returned once the
actual transaction fingerprint ID is written.

Related cockroachdb#74485.

Release note: None
Azhng added a commit to Azhng/cockroach that referenced this issue Jan 26, 2022
Previously, the transaction ID cache recorded the mapping from
transaction ID to transaction fingerprint ID once the transaction
finished executing. This introduced a problem where, when we queried the
transaction ID cache with a transaction ID, and we were not able to
distinguish between the case where transaction ID entry was being
evicted, or the transaction with that ID was still executing.

This commit addresses this problem by immediately starting a write
operation to write a provisional transaction fingerprint ID into
transaction ID cache once the transaction ID for a transaction is
determined. This is then followed up with additional write operation
once the transaction finishes execution where the transaction
fingerprint ID is then determined. Since transaction ID Cache always
returns the most-recent written value for a given key, the the
provisional transaction fingerprint ID will not be returned once the
actual transaction fingerprint ID is written.

Related cockroachdb#74485.

Release note: None
@Azhng Azhng self-assigned this Feb 16, 2022
@maryliag maryliag moved this from 22.2 to Backlog in Cluster Observability Sep 23, 2022
@maryliag maryliag closed this as completed Nov 3, 2023
Cluster Observability automation moved this from Backlog to Done Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sql-observability Related to observability of the SQL layer C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Projects
No open projects
Development

No branches or pull requests

2 participants