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.

Sign up for GitHub

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

Jump to bottom

sql: don't parallelize *any* FK and unique checks containing locking #118722

Merged
merged 3 commits into from
Feb 6, 2024
Merged

sql: don't parallelize *any* FK and unique checks containing locking #118722

merged 3 commits into from
Feb 6, 2024

Commits on Feb 6, 2024

  1. sql, execbuilder: move plan flags from planTop to planComponents 

    Execbuild produces a `sql.planComponents` containing the main query
plan, plus plans for any subqueries, checks, and cascades. In the normal
SQL code path (`sql.(*optPlanningCtx).runExecBuilder`) we copy this
planComponents into a `sql.planTop`, which then is decorated with extra
information gathered from the Builder.

However, there are other users of execbuild that only work with the
planComponents, and don't have a planTop. In the next commit, one such
user, `PlanAndRunCascadesAndChecks`, needs to see some of the plan flags
set when building FK check plans, but doesn't have access to the Builder
which gathered those plans.

To solve this, this commit moves plan flags from the planTop to
planComponents, and then refactors the execbuilder and exec factory to
set some of these flags when creating the planComponents.

Informs: cockroachdb#118720

Epic: None

Release note: None
    @michae2
    michae2 committed Feb 6, 2024
    Configuration menu
    Copy the full SHA
    ce49a6f View commit details
    Browse the repository at this point in the history

  2. sql: don't parallelize *any* FK and unique checks containing locking 

    In cockroachdb#111896 we disallowed parallel execution of FK and unique checks that
contain locking, to avoid usage of LeafTxns. But cockroachdb#111896 only considered
checks built during planning of the main query, and overlooked checks
built during planning of FK cascades.

This commit also considers checks built during planning of FK cascades.

Fixes: cockroachdb#118720

Epic: None

Release note (bug fix): This commit fixes an internal error with message
like: "LeafTxn ... incompatible with locking request" that occurs when
performing an update under read committed isolation which cascades to a
table with multiple other foreign keys.
    @michae2
    michae2 committed Feb 6, 2024
    Configuration menu
    Copy the full SHA
    38a0d6e View commit details
    Browse the repository at this point in the history

  3. sql: rename *ContainsNonDefaultKeyLocking to *ContainsLocking 

    "Default" locking here simply means no locking. I find this convention
of saying "non-default key locking" a little verbose and confusing.

Epic: None

Release note: None
    @michae2
    michae2 committed Feb 6, 2024
    Configuration menu
    Copy the full SHA
    5021627 View commit details
    Browse the repository at this point in the history