-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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: optimizer panics during index recommendation generation should not crash nodes #88246
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
S-1
High impact: many users impacted, serious risk of high unavailability or data loss
T-sql-queries
SQL Queries Team
Comments
mgartner
added
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
S-1
High impact: many users impacted, serious risk of high unavailability or data loss
labels
Sep 20, 2022
We should address this soon. |
I think we need panic-catching code in |
michae2
added a commit
to michae2/cockroach
that referenced
this issue
Nov 11, 2022
In the optimizer we have the convention of using panics for error propagation, to avoid adding error handling code everywhere in deeply recursive call stacks. This is safe because the optimizer is single- threaded and not manipulating locks, shared state, etc. But it means that wherever we call into the optimizer we need to add panic recovery. We were duplicating the same basic block of panic recovery code in all these places. Factor it into a "catch" function, somewhat similar to the vectorized engine's `CatchVectorizedRuntimeError`.` Assists: cockroachdb#88246 Release note: None
craig bot
pushed a commit
that referenced
this issue
Nov 11, 2022
91457: sql: catch panics in makeQueryIndexRecommendation r=DrewKimball,yuzefovich a=michae2 In the optimizer we use the convention of panic-based error handling for a performance advantage. This means at the boundaries we must remember to recover and return errors instead of letting panics escape. `sql.(*optPlanningCtx).makeQueryIndexRecommendation` calls some optimizer helper functions in addition to calling `xform.(*Optimizer).Optimize`. While `Optimize` has the panic-recovery code, these helper functions do not, so we need to add panic recovery to `makeQueryIndexRecommendation` as well. Fixes: #88246 Release note: None Co-authored-by: Michael Erickson <[email protected]>
blathers-crl bot
pushed a commit
that referenced
this issue
Nov 11, 2022
In the optimizer we use the convention of panic-based error handling for a performance advantage. This means at the boundaries we must remember to recover and return errors instead of letting panics escape. `sql.(*optPlanningCtx).makeQueryIndexRecommendation` calls some optimizer helper functions in addition to calling `xform.(*Optimizer).Optimize`. While `Optimize` has the panic-recovery code, these helper functions do not, so we need to add panic recovery to `makeQueryIndexRecommendation` as well. Fixes: #88246 Release note: None
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
S-1
High impact: many users impacted, serious risk of high unavailability or data loss
T-sql-queries
SQL Queries Team
See #88037.
If the optimizer panics while generating index recommendations, a node can crash. Below is the crash log from #88037 that shows an optimizer panic crashing the node.
Notice the line:
We need to correctly catch optimizer panics so that they do not crash nodes.
Jira issue: CRDB-19745
The text was updated successfully, but these errors were encountered: