release-26.1: sql: fix "rows written" metrics#167431
Merged
trunk-io[bot] merged 1 commit intocockroachdb:release-26.1from Apr 8, 2026
Merged
release-26.1: sql: fix "rows written" metrics#167431trunk-io[bot] merged 1 commit intocockroachdb:release-26.1from
trunk-io[bot] merged 1 commit intocockroachdb:release-26.1from
Conversation
This commit fixes a bug that was introduced long time ago in 03c09a3. In particular, in that change we began tracking "rows written" for the purposes of the guardrails, and later this information was also added into statement statistics as well as extended to some metrics. The bug was that we only check the first wrapped `planNode` for being a `mutationPlanNode`, but it's actually possible for a single `planNodeToRowSource` wrapper to wrap multiple `planNode`s at once. For example, if we have a mutation in the CTE, then we could have `bufferNode -> insertNode -> valuesNode`, all handled by a single wrapper. Previously, we would only check `bufferNode`, and since it's not a mutation planNode, we'd emit no "written" metrics. This commit fixes the issue by traversing the planNode tree until we either reach the first not-wrapped planNode (i.e. it's handled by DistSQL separately) or reach the leaf nodes. Note that this bug was further hidden by the fact that if we collect execution stats (which we do for stmt bundles and when the txn is sampled), then we wrap each planNode separately, so in those scenarios the behavior was correct. Release note (bug fix): Previously, if a mutation was executed in a subquery (e.g. as a CTE), the "rows written" metrics like `sql.statements.index_rows_written.count` and `sql.statements.index_bytes_written.count` might not be incremented correctly. This is now fixed.
blathers-crl
Bot
added
blathers-backport
|
Thanks for opening a backport. Before merging, please confirm that the change does not break backwards compatibility and otherwise complies with the backport policy. Include a brief release justification in the PR description explaining why the backport is appropriate. All backports must be reviewed by the TL for the owning area. While the stricter LTS policy does not yet apply, please exercise judgment and consider gating non-critical changes behind a disabled-by-default feature flag when appropriate. |
Contributor
|
😎 Merged successfully - details. |
blathers-crl
Bot
added
backport
Member
|
This change is |
mw5h
approved these changes
Apr 7, 2026
|
Detected infrastructure failure on trunk-merge branch (matched: self-hosted runner lost communication with the server). Please resubmit by commenting |
Member
Author
|
/trunk merge |
celeste-cockroachdb
Bot
added
target-release-26.1.4
and removed
target-release-26.1.3
labels
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport 1/1 commits from #167360 on behalf of @yuzefovich.
This commit fixes a bug that was introduced long time ago in 03c09a3. In particular, in that change we began tracking "rows written" for the purposes of the guardrails, and later this information was also added into statement statistics as well as extended to some metrics.
The bug was that we only check the first wrapped
planNodefor being amutationPlanNode, but it's actually possible for a singleplanNodeToRowSourcewrapper to wrap multipleplanNodes at once. For example, if we have a mutation in the CTE, then we could havebufferNode -> insertNode -> valuesNode, all handled by a single wrapper. Previously, we would only checkbufferNode, and since it's not a mutation planNode, we'd emit no "written" metrics.This commit fixes the issue by traversing the planNode tree until we either reach the first not-wrapped planNode (i.e. it's handled by DistSQL separately) or reach the leaf nodes.
Note that this bug was further hidden by the fact that if we collect execution stats (which we do for stmt bundles and when the txn is sampled), then we wrap each planNode separately, so in those scenarios the behavior was correct.
Epic: None
Release note (bug fix): Previously, if a mutation was executed in a subquery (e.g. as a CTE), the "rows written" metrics like
sql.statements.index_rows_written.countandsql.statements.index_bytes_written.countmight not be incremented correctly. This is now fixed.Release justification: low-risk observability bug fix.