Repository navigation
Commit dd285ce
committed
Fix 0-row result when re-executing a cached prepared statement scanning a python object
Re-executing the same statement that scans a pandas/polars/pyarrow object
(e.g. two LOAD FROM df queries on one connection) returned 0 rows on every
execution after the first.
Root cause: with the physical-plan cache enabled, the cached operator tree
template is cloned via TableFunctionCall::copy(), which shares the same
TableFuncSharedState instance between the template and its copies. The first
execution advanced PyArrowTableScanSharedState::currentChunk to the end of
the chunk list, and the shared state's resetState() was the base-class
no-op, so prepareForReuse() never rewound the cursor and subsequent
executions scanned zero chunks.
Fix: override resetState() in PyArrowTableScanSharedState to reset
currentChunk to 0.
Includes a regression test that executes the same LOAD FROM df query three
times and asserts each execution returns the full row count.1 parent eed4d5d commit dd285ce
2 files changed
Lines changed: 17 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
26 | 26 | | |
27 | 27 | | |
28 | 28 | | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
29 | 34 | | |
30 | 35 | | |
31 | 36 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
141 | 141 | | |
142 | 142 | | |
143 | 143 | | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
| 147 | + | |
| 148 | + | |
| 149 | + | |
| 150 | + | |
| 151 | + | |
| 152 | + | |
| 153 | + | |
| 154 | + | |
| 155 | + | |
144 | 156 | | |
145 | 157 | | |
146 | 158 | | |
| |||
0 commit comments