pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix bug in nbtree array primitive scan scheduling. 2+ messages / 1 participants [nested] [flat]
* pgsql: Fix bug in nbtree array primitive scan scheduling. @ 2024-10-30 14:58 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 2+ messages in thread From: Peter Geoghegan @ 2024-10-30 14:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bug in nbtree array primitive scan scheduling. A bug in nbtree's handling of primitive index scan scheduling could lead to wrong answers when a scrollable cursor was used with an index scan that had a SAOP index qual. Wrong answers were only possible when the scan direction changed after a primitive scan was scheduled, but before _bt_next was asked to fetch the next tuple in line (i.e. for things to break, _bt_next had to be denied the opportunity to step off the page in the same direction as the one used when the primscan was scheduled). Furthermore, the issue only occurred when the page in question happened to be the first page to be visited by the entire top-level scan; the issue hinged upon the cursor backing up to the absolute beginning of the key space that it returns tuples from (fetching in the opposite scan direction across a "primitive scan boundary" always worked correctly). To fix, make _bt_next unset the "needs primitive index scan" flag when it detects that the current scan direction is not the one that was used by _bt_readpage back when the primitive scan in question was scheduled. This fixes the cases that are known to be faulty, and also seems like a good idea on general robustness grounds. Affected scrollable cursor cases now avoid a spurious primitive index scan when they fetch backwards to the absolute start of the key space to be visited by their cursor. Fetching backwards now only returns those tuples at the start of the scan, as expected. It'll also be okay to once again fetch forwards from the start at that point, since the scan will be left in a state that's exactly consistent with the state it was in before any tuples were ever fetched, as expected. Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-Wznv49bFsE2jkt4GuZ0tU2C91dEST=50egzjY2FeOcHL4Q@mail.gmail.com Backpatch: 17-, where commit 5bf748b8 first appears. Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c177726ae41a4c13c575f2adf8942687fb6ec954 Modified Files -------------- src/backend/access/nbtree/nbtsearch.c | 14 +++++++++++--- src/backend/access/nbtree/nbtutils.c | 6 ++++-- 2 files changed, 15 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Fix bug in nbtree array primitive scan scheduling. @ 2024-10-30 14:58 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 2+ messages in thread From: Peter Geoghegan @ 2024-10-30 14:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bug in nbtree array primitive scan scheduling. A bug in nbtree's handling of primitive index scan scheduling could lead to wrong answers when a scrollable cursor was used with an index scan that had a SAOP index qual. Wrong answers were only possible when the scan direction changed after a primitive scan was scheduled, but before _bt_next was asked to fetch the next tuple in line (i.e. for things to break, _bt_next had to be denied the opportunity to step off the page in the same direction as the one used when the primscan was scheduled). Furthermore, the issue only occurred when the page in question happened to be the first page to be visited by the entire top-level scan; the issue hinged upon the cursor backing up to the absolute beginning of the key space that it returns tuples from (fetching in the opposite scan direction across a "primitive scan boundary" always worked correctly). To fix, make _bt_next unset the "needs primitive index scan" flag when it detects that the current scan direction is not the one that was used by _bt_readpage back when the primitive scan in question was scheduled. This fixes the cases that are known to be faulty, and also seems like a good idea on general robustness grounds. Affected scrollable cursor cases now avoid a spurious primitive index scan when they fetch backwards to the absolute start of the key space to be visited by their cursor. Fetching backwards now only returns those tuples at the start of the scan, as expected. It'll also be okay to once again fetch forwards from the start at that point, since the scan will be left in a state that's exactly consistent with the state it was in before any tuples were ever fetched, as expected. Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-Wznv49bFsE2jkt4GuZ0tU2C91dEST=50egzjY2FeOcHL4Q@mail.gmail.com Backpatch: 17-, where commit 5bf748b8 first appears. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/763d65ae254569e0bdbe2cbb27b184112765f24f Modified Files -------------- src/backend/access/nbtree/nbtsearch.c | 15 +++++++++++++-- src/backend/access/nbtree/nbtutils.c | 13 ++++++++----- src/include/access/nbtree.h | 1 - 3 files changed, 21 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-10-30 14:58 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-10-30 14:58 pgsql: Fix bug in nbtree array primitive scan scheduling. Peter Geoghegan <pg@bowt.ie> 2024-10-30 14:58 pgsql: Fix bug in nbtree array primitive scan scheduling. 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