pgsql: Fix Parallel TID Range Scan rescans with a different TID range

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 <zsolt(dot)parragi(at)percona(dot)com>
Author: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Author: David Rowley <dgrowleyml(at)gmail(dot)com>
Reviewed-by: David Rowley <dgrowleyml(at)gmail(dot)com>
Reviewed-by: shihao zhong <zhong950419(at)gmail(dot)com>
Discussion: https://postgr.es/m/CAN4CZFOoyCQE483YVGg07_Vr2MjFCTiCLUHUAFCwKqJAE=PN6w@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(+)