Fix Parallel TID Range Scan rescans with a different TID range
0ca3b1697 added support for parallel TID Range Scans. The range of
blocks to scan is stored in the shared phs_startblock and phs_numblock
fields by the first participant to start the scan, but
table_block_parallelscan_reinitialize() didn't reset these, so every
rescan of the Gather reused the block range of the first execution.
This caused rows to be silently missed when a rescan used a different
TID range, e.g:
SELECT r.lo, (SELECT count(*) FROM t WHERE ctid >= (SELECT r.lo))
FROM (VALUES ('(30,0)'::tid), ('(10,0)'), ('(0,0)')) r(lo);
Here we fix this by resetting both fields in
table_block_parallelscan_reinitialize(). As a side effect, a rescanned
Parallel Seq Scan using synchronized scans now gets a new start
location, which is what a new scan would do anyway.
The existing rescan test didn't exercise this, so add one that does.
This was introduced in 0ca3b1697, so backpatch to v19.
Reported-by: Zsolt Parragi <[email protected]>
Author: Zsolt Parragi <[email protected]>
Author: David Rowley <[email protected]>
Reviewed-by: David Rowley <[email protected]>
Reviewed-by: shihao zhong <[email protected]>
Discussion:
https://postgr.es/m/CAN4CZFOoyCQE483YVGg07_Vr2MjFCTiCLUHUAFCwKqJAE=p...@mail.gmail.com
Backpatch-through: 19
Branch
------
REL_19_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/93d48c6516fcc1e4aa62ca79cba440ab47324353
Modified Files
--------------
src/backend/access/table/tableam.c | 11 +++++++++++
src/test/regress/expected/tidrangescan.out | 31 ++++++++++++++++++++++++++++++
src/test/regress/sql/tidrangescan.sql | 12 ++++++++++++
3 files changed, 54 insertions(+)
