Horton

nbtree's ScalarArrayOp array mark/restore code appears to be buggy

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-09-23T03:17:16Z
Lists: pgsql-hackers

Attachments

Attached test case demonstrates an issue with nbtree's mark/restore
code. All supported versions are affected.

My suspicion is that bugfix commit 70bc5833 missed some subtlety
around what we need to do to make sure that the array keys stay "in
sync" with the scan. I'll have time to debug the problem some more
tomorrow.

My ScalarArrayOp project [1] seems unaffected by the bug, so I don't
expect it'll take long to get to the bottom of this. This is probably
due to its general design, and not any specific detail. The patch
makes the relationship between the current scan position and the
current array keys a great deal looser.

[1] https://commitfest.postgresql.org/44/4455/
-- 
Peter Geoghegan

Commits

  1. Fix btmarkpos/btrestrpos array key wraparound bug.

  2. Fix btmarkpos/btrestrpos to handle array keys.