Open yuzefovich opened 3 years ago
We have marked this issue as stale because it has been inactive for 18 months. If this issue is still relevant, removing the stale label or adding a comment will keep it active. Otherwise, we'll close it in 10 days to keep the issue queue tidy. Thank you for your contribution to CockroachDB!
With the merge of #62221 we attempt to precisely attribute "meta" objects to their corresponding tree and try to hand off the responsibility of handling them once a component that is able to take over is created. However, we currently don't have any testing in place that would verify that this tracking is correct - we should add something.
One idea on how to add the testing of this is to introduce
EXPLAIN (VEC, DEBUG)
(or something similar) that would create the operator tree and would print out each "meta" object associated with the correspondingexecinfra.OpNode
.For example, while working on another issue I noticed that we currently have at least one bug in this tracking. Consider the following scenario:
Note that this plan contains two materializers (components that we try to give the responsibility over meta objects once the materializers are created). In this example
ColBatchScan
is at least one metadata source. Ideally, we would give the ownership over it to the materializer (2), but we currently give it to the root materializer (1). What's happening is that we have aFilterer
core that we're able to vectorize which is followed by aPostProcessSpec
with a render expression that we don't support. The latter is handled by planning viawrapPostProcessSpec
which creates an artificial (and incompletecolexecargs.InputWithMetaInfo
), so the materializer (2) doesn't get any meta objects to take over.Here is an example why this imprecise tracking is problematic. Consider the same example as above but with the execution statistics being collected. At the moment of writing, the root materializer (1) will "own" two stats collectors (around the columnarizer and the around the colbatchscan). Now imagine that for some reason
selBoolOp
encounters a panic in itsInit
method. The panic will be caught by the materializer (2) which will transition into the draining state right away.However, the panic is not propagated any further, so from the perspective of the root materializer (1), the initialization of its input
Columnarizer
succeeded, so the materializer (1) will happily first attempt to g roetws from the columnarizer (there will be none) and then will attempt to retrieve execution stats from both of "its owned" stats collectors. Retrieving the stats from the colbatchscan will fail because it wasn't properly initialized.Once the tracking is fixed, the materializer (2) will own the stats collector around the colbatchscan and will not attempt to retrieve the stats because the materializer (2) knows that the initialization wasn't proper.
Jira issue: CRDB-6969