rowexec: tableReader can be accessed after being Released #88964
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
T-sql-queries
SQL Queries Team
Found when working on #88608.
Currently we have an issue where a
tableReader
(the only row-by-row processor allocation of which issync.Pool
ed) can be accessed even after it has beenRelease
d. In particular, this could occur if the tableReader is part of the subquery tree withrowSourceToPlanNode
adapter having it as input. We defer the closure of the subqueryplanNode
tree until after the main query is executed, androwSourceToPlanNode.Close
callsConsumerClosed
on its input. However, the processors from the subquery are released when the subquery execution finishes, so thatConsumerClosed
call can occur on a processor that was already put back into the pool (and possibly even picked up from the pool by another query).This is a very old issue (dating at least to #38866), and with the move to the vectorized engine we are now unlikely to use the table reader processor. However, #88608 wanted to pool more processors, so the issue becomes more pressing.
Jira issue: CRDB-20057
The text was updated successfully, but these errors were encountered: