-
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: add support for executing postqueries #38281
Conversation
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 (waiting on @jordanlewis and @RaduBerinde)
pkg/sql/distsql_running.go, line 925 at r1 (raw file):
return deferredSubqueryRecv.commErr } return deferredSubqueryRowReceiver.Err()
Not sure if this is needed (whether this should be return nil
): I'm a little confused by the comment above DistSQLReceiver.commErr
.
pkg/sql/plan.go, line 330 at r1 (raw file):
// deferredSubquery is a query tree that is executed after the main one. It can // only return an error (for example, foreign key violation). type deferredSubquery struct {
Not sure what the best name for this is. Suggestions are welcome.
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.
Thanks, it will be exciting to wire this up to my prototype!
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @jordanlewis and @RaduBerinde)
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! 1 of 0 LGTMs obtained (waiting on @jordanlewis, @RaduBerinde, and @yuzefovich)
pkg/sql/distsql_running.go, line 909 at r1 (raw file):
deferredSubqueryPlanCtx.stmtType = tree.Rows // Don't close the top-level plan from deferred subqueries - someone else // will handle that.
I think in this case we actually do need to close all the top level plans. The comment about this in the other code path is because subqueries are also going to be closed via the main planNode tree. In our cases, we have the only reference to the postqueries.
pkg/sql/distsql_running.go, line 939 at r1 (raw file):
func (r *deferredSubqueryRowResultWriter) AddRow(ctx context.Context, row tree.Datums) error { // TODO(yuzefovich): should we panic here since this should never be called?
How about returning an internal error?
pkg/sql/distsql_running.go, line 944 at r1 (raw file):
func (r *deferredSubqueryRowResultWriter) IncrementRowsAffected(n int) { // TODO(yuzefovich): should we panic here since this should never be called?
I think this one could be called one day once we implement cascade.
pkg/sql/plan.go, line 302 at r1 (raw file):
// deferredSubqueryPlans contains all the plans for subqueries that are to be // executed after the main query (for example, foreign keys checks).
nit: s/keys/key/
pkg/sql/plan.go, line 330 at r1 (raw file):
Previously, yuzefovich wrote…
Not sure what the best name for this is. Suggestions are welcome.
What about postquery
?
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 @jordanlewis)
pkg/sql/distsql_running.go, line 909 at r1 (raw file):
Previously, jordanlewis (Jordan Lewis) wrote…
I think in this case we actually do need to close all the top level plans. The comment about this in the other code path is because subqueries are also going to be closed via the main planNode tree. In our cases, we have the only reference to the postqueries.
Oh, thanks, makes sense.
pkg/sql/distsql_running.go, line 939 at r1 (raw file):
Previously, jordanlewis (Jordan Lewis) wrote…
How about returning an internal error?
Done. I forget that now we're using internal errors instead of panics in order to not crash the nodes.
pkg/sql/distsql_running.go, line 944 at r1 (raw file):
Previously, jordanlewis (Jordan Lewis) wrote…
I think this one could be called one day once we implement cascade.
Ok, left a TODO.
pkg/sql/plan.go, line 302 at r1 (raw file):
Previously, jordanlewis (Jordan Lewis) wrote…
nit: s/keys/key/
Done.
pkg/sql/plan.go, line 330 at r1 (raw file):
Previously, jordanlewis (Jordan Lewis) wrote…
What about
postquery
?
I like it - it has a nice symmetry with "subqueries."
pkg/sql/plan.go, line 330 at r1 (raw file): Previously, yuzefovich wrote…
👍 |
We should also add some kind of way of showing these queries in |
Would be good to rebase this when you can, it's hard to work on top of it and on top of other recent changes I merged. |
Rebased. @jordanlewis do you want to take another look? |
Let's do it in a separate PR. I'll open an issue. |
Are we cleaning up everything after the postqueries? I built something on top of f03b5bb91b and got this:
|
This commit introduces infrastructure for running "deferred subqueries" that are to be executed after the execution of the main query tree which is needed for (among other things) for foreign key checks. Release note: None
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.
I fixed the closing issue, but now running logic tests on Radu's WIP gives:
expected success, but found
(XXUUU) TransactionStatusError: client already committed or rolled back the transaction. Trying to execute: Scan [/Table/53/1/1,/Table/53/1/1/#) (REASON_UNKNOWN)
My guess is that kv fetcher is somehow closed when we're executing the postquery after we executed the main query (this error appears when we're initializing a table reader for the postquery), but I didn't get much further than that.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @jordanlewis)
pkg/sql/distsql_running.go, line 909 at r1 (raw file):
Previously, yuzefovich wrote…
Oh, thanks, makes sense.
I reverted to ignoreClose = true
and added a manual closure. The reason is that planner.curPlan
, as is, is always the main query, so if we keep ignoreClose = false
, then the main query tree is closed multiple times whereas the postqueries remain open.
I looked around a bit. It may be due to the tablewriter using |
Yeah, that worked. LGTM, thanks! |
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! 1 of 0 LGTMs obtained (and 1 stale) (waiting on @jordanlewis and @yuzefovich)
pkg/sql/distsql_running.go, line 909 at r1 (raw file):
Previously, yuzefovich wrote…
I reverted to
ignoreClose = true
and added a manual closure. The reason is thatplanner.curPlan
, as is, is always the main query, so if we keepignoreClose = false
, then the main query tree is closed multiple times whereas the postqueries remain open.
Ah I see. Okay, sorry about that.
TFTRs! bors r+ |
38281: sql: add support for executing postqueries r=yuzefovich a=yuzefovich This commit introduces infrastructure for running "deferred subqueries" that are to be executed after the execution of the main query tree which is needed for (among other things) for foreign key checks. Release note: None Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com>
Build succeeded |
This commit introduces infrastructure for running "deferred
subqueries" that are to be executed after the execution of the main
query tree which is needed for (among other things) for foreign key
checks.
Release note: None