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: fix crash when planning stats collection on virtual col with UDT #123926
Conversation
I kept the plumbing from 3f3223b but if you think I should revert it, let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job figuring this out! I only have a couple of nits - up to you.
Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @michae2)
pkg/sql/create_stats.go
line 649 at r1 (raw file):
// p is a second planner distinct from the "outer planner" in the // createStatsNode. It comes from the jobs system and does not have an // associated trx.
nit: I think we generally use txn
rather than trx
for short for "transaction". (Here and in the logic test.)
pkg/sql/create_stats.go
line 650 at r1 (raw file):
// createStatsNode. It comes from the jobs system and does not have an // associated trx. p := execCtx.(JobExecContext)
nit: should we rename this p
to something like jobsPlanner
to highlight where it's used?
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 v23.2.5 and 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 v23.2.4 and v24.1.0-alpha.1.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @yuzefovich)
pkg/sql/create_stats.go
line 649 at r1 (raw file):
Previously, yuzefovich (Yahor Yuzefovich) wrote…
nit: I think we generally use
txn
rather thantrx
for short for "transaction". (Here and in the logic test.)
Good catch! (I make this typo frequently.)
pkg/sql/create_stats.go
line 650 at r1 (raw file):
Previously, yuzefovich (Yahor Yuzefovich) wrote…
nit: should we rename this
p
to something likejobsPlanner
to highlight where it's used?
Good call, done.
TFYR! bors r=yuzefovich |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from 568c525 to blathers/backport-release-23.2-123926: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 23.2.x failed. See errors above. error creating merge commit from 568c525 to blathers/backport-release-24.1-123926: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 24.1.x failed. See errors above. error creating merge commit from 568c525 to blathers/backport-release-24.1.0-rc-123926: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 24.1.0-rc failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Move the definition of evalCtx down to match the backports of cockroachdb#123926. Informs: cockroachdb#123821 Release note: None
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 v23.2.5 and 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 v23.2.4 and v24.1.0-alpha.1.)