pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. @ 2023-09-28 23:30 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2023-09-28 23:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix btmarkpos/btrestrpos array key wraparound bug. nbtree's mark/restore processing failed to correctly handle an edge case involving array key advancement and related search-type scan key state. Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore processing (for a merge join) could incorrectly conclude that an affected array/scan key must not have advanced during the time between marking and restoring the scan's position. As a result of all this, array key handling within btrestrpos could skip a required call to _bt_preprocess_keys(). This confusion allowed later primitive index scans to overlook tuples matching the true current array keys. The scan's search-type scan keys would still have spurious values corresponding to the final array element(s) -- not values matching the first/now-current array element(s). To fix, remember that "array key wraparound" has taken place during the ongoing btrescan in a flag variable stored in the scan's state, and use that information at the point where btrestrpos decides if another call to _bt_preprocess_keys is required. Oversight in commit 70bc5833, which taught nbtree to handle array keys during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com Backpatch: 11- (all supported branches). Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/714780dcddf01865aa4323fedec59ffbefc7e707 Modified Files -------------- src/backend/access/nbtree/nbtree.c | 1 + src/backend/access/nbtree/nbtutils.c | 17 ++++++++++++++++- src/include/access/nbtree.h | 2 ++ 3 files changed, 19 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. @ 2023-09-28 23:30 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2023-09-28 23:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix btmarkpos/btrestrpos array key wraparound bug. nbtree's mark/restore processing failed to correctly handle an edge case involving array key advancement and related search-type scan key state. Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore processing (for a merge join) could incorrectly conclude that an affected array/scan key must not have advanced during the time between marking and restoring the scan's position. As a result of all this, array key handling within btrestrpos could skip a required call to _bt_preprocess_keys(). This confusion allowed later primitive index scans to overlook tuples matching the true current array keys. The scan's search-type scan keys would still have spurious values corresponding to the final array element(s) -- not values matching the first/now-current array element(s). To fix, remember that "array key wraparound" has taken place during the ongoing btrescan in a flag variable stored in the scan's state, and use that information at the point where btrestrpos decides if another call to _bt_preprocess_keys is required. Oversight in commit 70bc5833, which taught nbtree to handle array keys during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com Backpatch: 11- (all supported branches). Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3fa81b62e09befc0e839b2e1ef9ea92ef854a77d Modified Files -------------- src/backend/access/nbtree/nbtree.c | 1 + src/backend/access/nbtree/nbtutils.c | 17 ++++++++++++++++- src/include/access/nbtree.h | 4 +++- 3 files changed, 20 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. @ 2023-09-28 23:30 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2023-09-28 23:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix btmarkpos/btrestrpos array key wraparound bug. nbtree's mark/restore processing failed to correctly handle an edge case involving array key advancement and related search-type scan key state. Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore processing (for a merge join) could incorrectly conclude that an affected array/scan key must not have advanced during the time between marking and restoring the scan's position. As a result of all this, array key handling within btrestrpos could skip a required call to _bt_preprocess_keys(). This confusion allowed later primitive index scans to overlook tuples matching the true current array keys. The scan's search-type scan keys would still have spurious values corresponding to the final array element(s) -- not values matching the first/now-current array element(s). To fix, remember that "array key wraparound" has taken place during the ongoing btrescan in a flag variable stored in the scan's state, and use that information at the point where btrestrpos decides if another call to _bt_preprocess_keys is required. Oversight in commit 70bc5833, which taught nbtree to handle array keys during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com Backpatch: 11- (all supported branches). Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/cac37c1a1b7c64e60832b764e3828a9aca95bc48 Modified Files -------------- src/backend/access/nbtree/nbtree.c | 1 + src/backend/access/nbtree/nbtutils.c | 17 ++++++++++++++++- src/include/access/nbtree.h | 4 +++- 3 files changed, 20 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. @ 2023-09-28 23:30 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2023-09-28 23:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix btmarkpos/btrestrpos array key wraparound bug. nbtree's mark/restore processing failed to correctly handle an edge case involving array key advancement and related search-type scan key state. Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore processing (for a merge join) could incorrectly conclude that an affected array/scan key must not have advanced during the time between marking and restoring the scan's position. As a result of all this, array key handling within btrestrpos could skip a required call to _bt_preprocess_keys(). This confusion allowed later primitive index scans to overlook tuples matching the true current array keys. The scan's search-type scan keys would still have spurious values corresponding to the final array element(s) -- not values matching the first/now-current array element(s). To fix, remember that "array key wraparound" has taken place during the ongoing btrescan in a flag variable stored in the scan's state, and use that information at the point where btrestrpos decides if another call to _bt_preprocess_keys is required. Oversight in commit 70bc5833, which taught nbtree to handle array keys during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com Backpatch: 11- (all supported branches). Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/41486c4aaeb10dcc948b2592168123df273a9e9d Modified Files -------------- src/backend/access/nbtree/nbtree.c | 1 + src/backend/access/nbtree/nbtutils.c | 17 ++++++++++++++++- src/include/access/nbtree.h | 4 +++- 3 files changed, 20 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. @ 2023-09-28 23:30 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2023-09-28 23:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix btmarkpos/btrestrpos array key wraparound bug. nbtree's mark/restore processing failed to correctly handle an edge case involving array key advancement and related search-type scan key state. Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore processing (for a merge join) could incorrectly conclude that an affected array/scan key must not have advanced during the time between marking and restoring the scan's position. As a result of all this, array key handling within btrestrpos could skip a required call to _bt_preprocess_keys(). This confusion allowed later primitive index scans to overlook tuples matching the true current array keys. The scan's search-type scan keys would still have spurious values corresponding to the final array element(s) -- not values matching the first/now-current array element(s). To fix, remember that "array key wraparound" has taken place during the ongoing btrescan in a flag variable stored in the scan's state, and use that information at the point where btrestrpos decides if another call to _bt_preprocess_keys is required. Oversight in commit 70bc5833, which taught nbtree to handle array keys during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com Backpatch: 11- (all supported branches). Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d4724e94a1ebc5ab5887372b99190d3b112fb06c Modified Files -------------- src/backend/access/nbtree/nbtree.c | 1 + src/backend/access/nbtree/nbtutils.c | 17 ++++++++++++++++- src/include/access/nbtree.h | 4 +++- 3 files changed, 20 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. @ 2023-09-28 23:30 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2023-09-28 23:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix btmarkpos/btrestrpos array key wraparound bug. nbtree's mark/restore processing failed to correctly handle an edge case involving array key advancement and related search-type scan key state. Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore processing (for a merge join) could incorrectly conclude that an affected array/scan key must not have advanced during the time between marking and restoring the scan's position. As a result of all this, array key handling within btrestrpos could skip a required call to _bt_preprocess_keys(). This confusion allowed later primitive index scans to overlook tuples matching the true current array keys. The scan's search-type scan keys would still have spurious values corresponding to the final array element(s) -- not values matching the first/now-current array element(s). To fix, remember that "array key wraparound" has taken place during the ongoing btrescan in a flag variable stored in the scan's state, and use that information at the point where btrestrpos decides if another call to _bt_preprocess_keys is required. Oversight in commit 70bc5833, which taught nbtree to handle array keys during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com Backpatch: 11- (all supported branches). Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b36d72cbc6b008da062ac84850254a9de0da93d4 Modified Files -------------- src/backend/access/nbtree/nbtree.c | 1 + src/backend/access/nbtree/nbtutils.c | 17 ++++++++++++++++- src/include/access/nbtree.h | 4 +++- 3 files changed, 20 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. @ 2023-09-28 23:30 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2023-09-28 23:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix btmarkpos/btrestrpos array key wraparound bug. nbtree's mark/restore processing failed to correctly handle an edge case involving array key advancement and related search-type scan key state. Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore processing (for a merge join) could incorrectly conclude that an affected array/scan key must not have advanced during the time between marking and restoring the scan's position. As a result of all this, array key handling within btrestrpos could skip a required call to _bt_preprocess_keys(). This confusion allowed later primitive index scans to overlook tuples matching the true current array keys. The scan's search-type scan keys would still have spurious values corresponding to the final array element(s) -- not values matching the first/now-current array element(s). To fix, remember that "array key wraparound" has taken place during the ongoing btrescan in a flag variable stored in the scan's state, and use that information at the point where btrestrpos decides if another call to _bt_preprocess_keys is required. Oversight in commit 70bc5833, which taught nbtree to handle array keys during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com Backpatch: 11- (all supported branches). Branch ------ REL_11_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7c07305e6f025a97732adb01ca6fcb499655a886 Modified Files -------------- src/backend/access/nbtree/nbtree.c | 1 + src/backend/access/nbtree/nbtutils.c | 17 ++++++++++++++++- src/include/access/nbtree.h | 4 +++- 3 files changed, 20 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2023-09-28 23:30 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-09-28 23:30 pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. Peter Geoghegan <pg@bowt.ie> 2023-09-28 23:30 pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. Peter Geoghegan <pg@bowt.ie> 2023-09-28 23:30 pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. Peter Geoghegan <pg@bowt.ie> 2023-09-28 23:30 pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. Peter Geoghegan <pg@bowt.ie> 2023-09-28 23:30 pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. Peter Geoghegan <pg@bowt.ie> 2023-09-28 23:30 pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. Peter Geoghegan <pg@bowt.ie> 2023-09-28 23:30 pgsql: Fix btmarkpos/btrestrpos array key wraparound bug. 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