pgsql: nbtree: Always set skipScan flag on rescan.

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: nbtree: Always set skipScan flag on rescan.
Date: 2025-09-14 01:02:14
Message-ID: E1uxb89-000adi-36@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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(at)bowt(dot)ie>
Reported-By: Natalya Aksman <natalya(at)timescale(dot)com>
Discussion: https://postgr.es/m/CAJumhcirfMojbk20+W0YimbNDkwdECvJprQGQ-XqK--ph09nQw@mail.gmail.com
Backpatch-through: 18

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/454c046094ab3431c2ce0c540c46e623bc05bd1a

Modified Files
--------------
src/backend/access/nbtree/nbtpreprocesskeys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Browse pgsql-committers by date

  From Date Subject
Previous Message Tom Lane 2025-09-13 20:56:15 pgsql: Amend recent fix for SIMILAR TO regex conversion.