release-22.2: sql: make transaction_rows_read_err prevent large scans

[rytaft]

Backport 1/1 commits from #104290.

/cc @cockroachdb/release

---

Prior to this commit, setting transaction_rows_read_err to a non-zero value would cause a transaction to fail as soon as a statement caused the total number of rows read to exceed transaction_rows_read_err. However, it was possible that each statement could read many more than transaction_rows_read_err rows. This commit adds logic so that a single scan never reads more than transaction_rows_read_err+1 rows if transaction_rows_read_err is set.

Informs #70473

Release note (performance improvement): If transaction_rows_read_err is set to a non-zero value, we now ensure that any single scan never reads more than transaction_rows_read_err+1 rows. This prevents transactions that would error due to the transaction_rows_read_err setting from causing a large performance overhead due to large scans. For some queries in rare cases this change may end up disabling cross-range parallelism of the scan operation which can result in increase of query latency.

---

Release justification: low-risk fix to reduce the likelihood of OOMs for customers

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is 

[yuzefovich]

Reviewed 13 of 13 files at r1, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @michae2 and @rytaft)

---

pkg/sql/opt/exec/execbuilder/testdata/guardrails line 74 at r1 (raw file):

  table: guardrails@guardrails_pkey
  spans: /1-/11
  limit: 2

Something that I wanted to point out on the original PR, then scratched it, and now I think it might be worth mentioning after all. The fact that we added a hard limit makes it so that we disable the parallelism of the scan. For example, in this query without the guardrail we'd be able to parallelize the scan across ranges.

So I'm wondering whether we should mention this caveat in the release note, something like "For some queries in rare cases this change may end up disabling cross-range parallelism of the scan operation which can result in increase of query latency." That said, cases when we can use the parallelism are few, so I'll leave it up to you to decide whether to adjust the release note.

[rytaft]

pkg/sql/opt/exec/execbuilder/testdata/guardrails line 74 at r1 (raw file):

Previously, yuzefovich (Yahor Yuzefovich) wrote…

Something that I wanted to point out on the original PR, then scratched it, and now I think it might be worth mentioning after all. The fact that we added a hard limit makes it so that we disable the parallelism of the scan. For example, in this query without the guardrail we'd be able to parallelize the scan across ranges.

So I'm wondering whether we should mention this caveat in the release note, something like "For some queries in rare cases this change may end up disabling cross-range parallelism of the scan operation which can result in increase of query latency." That said, cases when we can use the parallelism are few, so I'll leave it up to you to decide whether to adjust the release note.

Sure, I already merged the PRs on master and 23.1, though. I'll see if I can figure out how to change the release notes after the fact.