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

release-24.1: sql: fix crash when planning stats collection on virtual col with UDT #124060

Merged
merged 1 commit into from May 14, 2024

Conversation

michae2
Copy link
Collaborator

@michae2 michae2 commented May 13, 2024

Backport 1/1 commits from #123926.

/cc @cockroachdb/release


CREATE STATISTICS executes in multiple layers: the "outer" layer is a normal execution of the CREATE STATISTICS statement. During this execution, we create, start, and await a CreateStats job. The CreateStats job in turn starts an "inner" layer which uses a separate internal transaction to plan and execute distributed statistics collection.

Within the inner layer, we were using the job's planner (JobExecContext) to plan distributed stats collection. This planner has no associated transaction. If it weren't for user-defined types, this would be fine, but user-defined types must be resolved using a transaction.

We had a hack in place to set the evalCtx.Txn to the internal transaction in order to execute collection on normal columns with user-defined type. But this hack did not work for virtual computed columns with user-defined type, because type-checking their expressions uses more facilites of the planner than just the evalCtx. (Specifically the schemaResolver.)

So, instead of setting the evalCtx.Txn, we create a new "inner" planner that is associated with the internal transaction of the inner layer. This works for all columns with user-defined type.

Fixes: #123821

Release note (bug fix): Fix a crash introduced in v24.1.0-beta.2 that could occur when planning statistics collection on a table with a virtual computed column using a user-defined type when the newly-introduced cluster setting sql.stats.virtual_computed_columns.enabled is set to true. (The setting was introduced in v24.1.0-alpha.1 default true.)


Release justification: fix for GA-blocker node crash.

@michae2 michae2 requested a review from a team as a code owner May 13, 2024 18:46
Copy link

blathers-crl bot commented May 13, 2024

Thanks for opening a backport.

Please check the backport criteria before merging:

  • Backports should only be created for serious
    issues
    or test-only changes.
  • Backports should not break backwards-compatibility.
  • Backports should change as little code as possible.
  • Backports should not change on-disk formats or node communication protocols.
  • Backports should not add new functionality (except as defined
    here).
  • Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
  • All backports must be reviewed by the owning areas TL and one additional
    TL. For more information as to how that review should be conducted, please consult the backport
    policy
    .
If your backport adds new functionality, please ensure that the following additional criteria are satisfied:
  • 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. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
  • The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
  • Your backport must be accompanied by a post to the appropriate Slack
    channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

@blathers-crl blathers-crl bot added the backport Label PR's that are backports to older release branches label May 13, 2024
@michae2 michae2 removed the request for review from a team May 13, 2024 18:46
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Member

@yuzefovich yuzefovich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


pkg/sql/create_stats.go line 662 at r1 (raw file):

	r.tableID = details.Table.ID
	evalCtx := jobsPlanner.ExtendedEvalContext()

nit: it might be a bit cleaner to move this line below the Txn anonymous function.

Copy link
Collaborator Author

@michae2 michae2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @mgartner and @yuzefovich)


pkg/sql/create_stats.go line 662 at r1 (raw file):

Previously, yuzefovich (Yahor Yuzefovich) wrote…

nit: it might be a bit cleaner to move this line below the Txn anonymous function.

Good point, and this would have caught a bug introduced by backport skew... one minute.

Copy link
Collaborator

@mgartner mgartner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 1 of 2 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @yuzefovich)

CREATE STATISTICS executes in multiple layers: the "outer" layer is a
normal execution of the CREATE STATISTICS statement. During this
execution, we create, start, and await a CreateStats job. The
CreateStats job in turn starts an "inner" layer which uses a separate
internal transaction to plan and execute distributed statistics
collection.

Within the inner layer, we were using the job's planner (JobExecContext)
to plan distributed stats collection. This planner has no associated
transaction. If it weren't for user-defined types, this would be fine,
but user-defined types must be resolved using a transaction.

We had a hack in place to set the evalCtx.Txn to the internal
transaction in order to execute collection on normal columns with
user-defined type. But this hack did not work for virtual computed
columns with user-defined type, because type-checking their expressions
uses more facilites of the planner than just the evalCtx. (Specifically
the schemaResolver.)

So, instead of setting the evalCtx.Txn, we create a new "inner" planner
that is associated with the internal transaction of the inner
layer. This works for all columns with user-defined type.

Fixes: cockroachdb#123821

Release note (bug fix): Fix a crash introduced in v24.1.0-beta.2 that
could occur when planning statistics collection on a table with a
virtual computed column using a user-defined type when the
newly-introduced cluster setting
`sql.stats.virtual_computed_columns.enabled` is set to true. (The
setting was introduced in v24.1.0-alpha.1 default true.)
@michae2
Copy link
Collaborator Author

michae2 commented May 14, 2024

TFTRs! Trying to kick CI with a rebase...

@michae2 michae2 merged commit fc2171a into cockroachdb:release-24.1 May 14, 2024
19 of 20 checks passed
@michae2 michae2 deleted the backport24.1-123926 branch May 14, 2024 22:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport Label PR's that are backports to older release branches
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants