-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
opt: internal error due to outer variable in left side of join #46151
Comments
rytaft
added a commit
to rytaft/cockroach
that referenced
this issue
Mar 16, 2020
Prior to this commit, it was possible for a correlated subquery to go undetected if it was buried in a complex filter. In particular, a filter of the form: <correlated subquery> OR <non-correlated subquery> would incorrectly be marked as *not* containing a correlated subquery. This was because although the logical property HasCorrelatedSubquery was initially set to true upon encountering the first (correlated) subquery, the left-to-right recursive traversal of the OR expression caused HasCorrelatedSubquery to be overwritten to false upon encountering the second (non-correlated) subquery. This commit fixes the issue by never overwriting HasCorrelatedSubquery to false. Fixes cockroachdb#46151 Release note (bug fix): Fixed an internal error that could occur in the optimizer when a WHERE filter contained at least one correlated subquery and one non-correlated subquery. Release justification: This bug fix falls into the category "low risk, high benefit changes to existing functionality".
Also thanks to @RaduBerinde for narrowing down the root cause and the updates to |
rytaft
changed the title
opt: crash due to outer variable in left side of join
opt: internal error due to outer variable in left side of join
Mar 16, 2020
craig bot
pushed a commit
that referenced
this issue
Mar 16, 2020
46153: opt: fix detection of correlated subqueries in complex filters r=rytaft a=rytaft Prior to this commit, it was possible for a correlated subquery to go undetected if it was buried in a complex filter. In particular, a filter of the form: ``` <correlated subquery> OR <non-correlated subquery> ``` would incorrectly be marked as *not* containing a correlated subquery. This was because although the logical property `HasCorrelatedSubquery` was initially set to true upon encountering the first (correlated) subquery, the left-to-right recursive traversal of the `OR` expression caused `HasCorrelatedSubquery` to be overwritten to false upon encountering the second (non-correlated) subquery. This commit fixes the issue by never overwriting `HasCorrelatedSubquery` to false. Fixes #46151 Release note (bug fix): Fixed an internal error that could occur in the optimizer when a WHERE filter contained at least one correlated subquery and one non-correlated subquery. Release justification: This bug fix falls into the category "low risk, high benefit changes to existing functionality". 46160: vendor: Bump pebble to c50a7b1164d9b1a971f1729d84ff9cdb7e987496 r=itsbilal a=itsbilal Picks up these changes: - iterator: Copy iterValue before Prev() on internal iterator - db: add a section on RocksDB Compatibility - db: rework doc comment on Iterator.SeekPrefixGE Release justification: Bug fixes. Release note: None Co-authored-by: Rebecca Taft <[email protected]> Co-authored-by: Bilal Akhtar <[email protected]>
rytaft
added a commit
to rytaft/cockroach
that referenced
this issue
Mar 16, 2020
Prior to this commit, it was possible for a correlated subquery to go undetected if it was buried in a complex filter. In particular, a filter of the form: <correlated subquery> OR <non-correlated subquery> would incorrectly be marked as *not* containing a correlated subquery. This was because although the logical property HasCorrelatedSubquery was initially set to true upon encountering the first (correlated) subquery, the left-to-right recursive traversal of the OR expression caused HasCorrelatedSubquery to be overwritten to false upon encountering the second (non-correlated) subquery. This commit fixes the issue by never overwriting HasCorrelatedSubquery to false. Fixes cockroachdb#46151 Release note (bug fix): Fixed an internal error that could occur in the optimizer when a WHERE filter contained at least one correlated subquery and one non-correlated subquery. Release justification: This bug fix falls into the category "low risk, high benefit changes to existing functionality".
rytaft
added a commit
to rytaft/cockroach
that referenced
this issue
Mar 16, 2020
Prior to this commit, it was possible for a correlated subquery to go undetected if it was buried in a complex filter. In particular, a filter of the form: <correlated subquery> OR <non-correlated subquery> would incorrectly be marked as *not* containing a correlated subquery. This was because although the logical property HasCorrelatedSubquery was initially set to true upon encountering the first (correlated) subquery, the left-to-right recursive traversal of the OR expression caused HasCorrelatedSubquery to be overwritten to false upon encountering the second (non-correlated) subquery. This commit fixes the issue by never overwriting HasCorrelatedSubquery to false. Fixes cockroachdb#46151 Release note (bug fix): Fixed an internal error that could occur in the optimizer when a WHERE filter contained at least one correlated subquery and one non-correlated subquery. Release justification: This bug fix falls into the category "low risk, high benefit changes to existing functionality".
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To reproduce, create a database with the TPC-C schema, then run the following query:
It crashes with this error:
Thanks to the Apollo team at Georgia Tech for finding this issue.
The text was updated successfully, but these errors were encountered: