pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: nbtree: Always set skipScan flag on rescan. 2+ messages / 1 participants [nested] [flat]
* pgsql: nbtree: Always set skipScan flag on rescan. @ 2025-09-14 01:02 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 2+ messages in thread From: Peter Geoghegan @ 2025-09-14 01:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 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(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: nbtree: Always set skipScan flag on rescan. @ 2025-09-14 01:02 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 2+ messages in thread From: Peter Geoghegan @ 2025-09-14 01:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bee763aea13ff27ade2fe4704eaf6605b0ad4d65 Modified Files -------------- src/backend/access/nbtree/nbtpreprocesskeys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-09-14 01:02 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-09-14 01:02 pgsql: nbtree: Always set skipScan flag on rescan. Peter Geoghegan <pg@bowt.ie> 2025-09-14 01:02 pgsql: nbtree: Always set skipScan flag on rescan. Peter Geoghegan <pg@bowt.ie>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox