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: crash when collecting stats on virtual computed column with enum type #123821
Labels
A-sql-table-stats
Table statistics (and their automatic refresh).
A-sql-typing
SQLtype inference, typing rules, type compatibility.
branch-release-24.1
Used to mark GA and release blockers and technical advisories for 24.1
branch-release-24.1.0-rc
Used to mark GA and release blockers and technical advisories for 24.1.0-rc
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
GA-blocker
T-sql-queries
SQL Queries Team
Comments
michae2
added
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
A-sql-typing
SQLtype inference, typing rules, type compatibility.
A-sql-table-stats
Table statistics (and their automatic refresh).
T-sql-queries
SQL Queries Team
labels
May 8, 2024
michae2
added
GA-blocker
branch-release-24.1
Used to mark GA and release blockers and technical advisories for 24.1
branch-release-24.1.0-rc
Used to mark GA and release blockers and technical advisories for 24.1.0-rc
labels
May 8, 2024
michae2
added a commit
to michae2/cockroach
that referenced
this issue
May 10, 2024
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 that could occur when planning statistics collection on a table with a virtual computed column using a user-defined type.
michae2
added a commit
to michae2/cockroach
that referenced
this issue
May 10, 2024
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.)
craig bot
pushed a commit
that referenced
this issue
May 13, 2024
123926: sql: fix crash when planning stats collection on virtual col with UDT r=yuzefovich a=michae2 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.) Co-authored-by: Michael Erickson <michae2@cockroachlabs.com>
michae2
added a commit
to michae2/cockroach
that referenced
this issue
May 13, 2024
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
added a commit
to michae2/cockroach
that referenced
this issue
May 13, 2024
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
added a commit
to michae2/cockroach
that referenced
this issue
May 13, 2024
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
added a commit
to michae2/cockroach
that referenced
this issue
May 13, 2024
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 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 default false.)
michae2
added a commit
to michae2/cockroach
that referenced
this issue
May 13, 2024
Move the definition of evalCtx down to match the backports of cockroachdb#123926. Informs: cockroachdb#123821 Release note: None
michae2
added a commit
to michae2/cockroach
that referenced
this issue
May 14, 2024
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
added a commit
to michae2/cockroach
that referenced
this issue
May 14, 2024
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.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-sql-table-stats
Table statistics (and their automatic refresh).
A-sql-typing
SQLtype inference, typing rules, type compatibility.
branch-release-24.1
Used to mark GA and release blockers and technical advisories for 24.1
branch-release-24.1.0-rc
Used to mark GA and release blockers and technical advisories for 24.1.0-rc
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
GA-blocker
T-sql-queries
SQL Queries Team
In #122313 we fixed a missing type resolver when planning stats collection on virtual computed columns with enum types. But something is still not quite right, because now the following repro crashes the node with a nil pointer dereference during type checking.
Here's the stack trace on master (e0d587c):
Jira issue: CRDB-38560
The text was updated successfully, but these errors were encountered: