exec: protect against unset syncFlowConsumer #38557
Conversation
This should never happen since it implies that the receiver isn't connected correctly. These happen when a node sends a SetupFlow request to a remote node where the spec specifies that the response is on that remote node. We don't see panics in the row execution engine due to wrapping the syncFlowConsumer with a copyingRowReceiver, but this state can cause setupVectorized to panic. This commit protects against this state pending further investigation. Release note: None
|
This change is |
|
Looks like the ones causing these are internal executor queries: |
There was a problem hiding this comment.
Reviewable status:
complete! 1 of 0 LGTMs obtained (waiting on @asubiotto and @jordanlewis)
pkg/sql/distsqlrun/column_exec_setup.go, line 1080 at r1 (raw file):
case distsqlpb.StreamEndpointSpec_SYNC_RESPONSE: if f.syncFlowConsumer == nil { return errors.New("syncFlowConsumer unset, unable to create materializer")
When would this practically happen? It seems like kind of a weird case. Could this be pointing at an error case we're not catching or something?
There was a problem hiding this comment.
Reviewable status:
pkg/sql/distsqlrun/column_exec_setup.go, line 1080 at r1 (raw file):
Previously, jordanlewis (Jordan Lewis) wrote…
When would this practically happen? It seems like kind of a weird case. Could this be pointing at an error case we're not catching or something?
I190628 15:59:45.676023 3672 sql/distsql_running.go:180 [intExec=adopt-job] error vectorizing remote flow d6d8146f-f896-41d8-8c17-82bae5f1bbd3, restarting with vectorize=off and ID 10d20b4f-490d-48b6-943a-a1bc791f5102: syncFlowConsumer unset, unable to create materializer
I don't think this is an error case we're not catching, it seems like a bad plan output from the physical planner. This needs some more investigation for sure.
There was a problem hiding this comment.
Reviewable status:
pkg/sql/distsqlrun/column_exec_setup.go, line 1080 at r1 (raw file):
Previously, asubiotto (Alfonso Subiotto Marqués) wrote…
I190628 15:59:45.676023 3672 sql/distsql_running.go:180 [intExec=adopt-job] error vectorizing remote flow d6d8146f-f896-41d8-8c17-82bae5f1bbd3, restarting with vectorize=off and ID 10d20b4f-490d-48b6-943a-a1bc791f5102: syncFlowConsumer unset, unable to create materializer
I don't think this is an error case we're not catching, it seems like a bad plan output from the physical planner. This needs some more investigation for sure.
The common theme seems to be that these things are run through an internal executor, there might be something funky going on when setting up a receiver in those cases.
|
bors r=jordanlewis |
Build failed (retrying...) |
38557: exec: protect against unset syncFlowConsumer r=jordanlewis a=asubiotto This should never happen since it implies that the receiver isn't connected correctly. These happen when a node sends a SetupFlow request to a remote node where the spec specifies that the response is on that remote node. We don't see panics in the row execution engine due to wrapping the syncFlowConsumer with a copyingRowReceiver, but this state can cause setupVectorized to panic. This commit protects against this state pending further investigation. Release note: None 38613: exec: Add support for projection of the IN operator r=rohany a=rohany vectorized execution now supports statements of the form ``` select x, x IN (1,2,3) from t; ``` Co-authored-by: Alfonso Subiotto Marqués <alfonso@cockroachlabs.com> Co-authored-by: Rohan Yadav <rohany@alumni.cmu.edu>
Build succeeded |
This should never happen since it implies that the receiver isn't
connected correctly. These happen when a node sends a SetupFlow request
to a remote node where the spec specifies that the response is on that
remote node. We don't see panics in the row execution engine due to
wrapping the syncFlowConsumer with a copyingRowReceiver, but this state
can cause setupVectorized to panic.
This commit protects against this state pending further investigation.
Release note: None