You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sql: make sure that "inner" plans use the LeafTxn if the "outer" does
This commit fixes a bug where "inner" plans could incorrectly use
the RootTxn when the "outer" plan used the LeafTxn. One example of such
situation is when the "main" query is using the streamer (and thus is
using the LeafTxn) and also has an apply join, but the apply join
iteration plans would use the RootTxn. This could lead to "concurrent
txn usage" detected on the RootTxn. This problem is fixed by auditing
all code paths that might run plans that can spin up "inner" plans and
plumbing the information that the LeafTxn must be used by those "inner"
plans via the planner (we don't really have any other more convenient
place to do that plumbing).
Note that when create the flow for the main query we only know for sure
whether it'll use the LeafTxn or not only after the flow setup is
complete, so we adjust an existing `finishedSetupFn` callback to check
the type of the txn that the flow ends up using and update the planner
accordingly.
This bug reliably reproduces when creating a materialized view, but for
some (unknown to me) reason just running the query as is doesn't seem to
trigger the bug (I tried stressing the query with no luck and decided it
wasn't worth spending more time on it). I also believe that even though
the underlying mechanism for the bug has been present since forever, it
was really introduced only when we enabled the streamer by default in
22.2 (since without the streamer we always use the RootTxn for flows
with apply joins or UDFs - they must be local).
Release note (bug fix): CockroachDB previously could encounter
"concurrent txn use detected" internal error in some rare cases, and
this is now fixed. The bug was introduced in 22.2.0.
0 commit comments