]> git.ipfire.org Git - thirdparty/postgresql.git/commit
nbtree: Always set skipScan flag on rescan.
authorPeter Geoghegan <pg@bowt.ie>
Sun, 14 Sep 2025 01:01:31 +0000 (21:01 -0400)
committerPeter Geoghegan <pg@bowt.ie>
Sun, 14 Sep 2025 01:01:31 +0000 (21:01 -0400)
commitbee763aea13ff27ade2fe4704eaf6605b0ad4d65
tree9cb6383efa29e3aff2a3318ebaef184eb48865d3
parent802308693f2f55704751657986abdc81f76ee4cf
nbtree: Always set skipScan flag on rescan.

The TimescaleDB extension expects to be able to change an nbtree scan's
keys across rescans.  The issue arises in the extension's implementation
of loose index scan.  This is arguably a misuse of the index AM API,
though apparently it worked until recently.  It stopped working when the
skipScan flag was added to BTScanOpaqueData by commit 8a510275, though.
The flag wouldn't reliably track whether the scan (actually, the current
rescan) has any skip arrays, leading to confusion in _bt_set_startikey.

nbtree preprocessing will now defensively initialize the scan's skipScan
flag in all cases, including the case where _bt_preprocess_array_keys
returns early due to the (re)scan not using arrays.  While nbtree isn't
obligated to support this use case (at least not according to my reading
of the index AM API), it still seems like a good idea to be consistent
here, on general robustness grounds.

Author: Peter Geoghegan <pg@bowt.ie>
Reported-By: Natalya Aksman <natalya@timescale.com>
Discussion: https://postgr.es/m/CAJumhcirfMojbk20+W0YimbNDkwdECvJprQGQ-XqK--ph09nQw@mail.gmail.com
Backpatch-through: 18
src/backend/access/nbtree/nbtpreprocesskeys.c