pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: GiST: Invalidate killed items consistently. 7+ messages / 1 participants [nested] [flat]
* pgsql: GiST: Invalidate killed items consistently. @ 2026-08-19 19:46 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-19 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org GiST: Invalidate killed items consistently. GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bf25c5f832fed181505bbbd46f8ce17a2583b79f Modified Files -------------- src/backend/access/gist/gistget.c | 4 ++++ src/backend/access/gist/gistscan.c | 8 ++++++++ 2 files changed, 12 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: GiST: Invalidate killed items consistently. @ 2026-08-19 19:46 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-19 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org GiST: Invalidate killed items consistently. GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d7ce15e4de6fdfcab6fb813e74daba5511e64a4b Modified Files -------------- src/backend/access/gist/gistget.c | 4 ++++ src/backend/access/gist/gistscan.c | 8 ++++++++ 2 files changed, 12 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: GiST: Invalidate killed items consistently. @ 2026-08-19 19:46 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-19 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org GiST: Invalidate killed items consistently. GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/29f7881a5fdb6f0282a32bdb4fe7ef3c03e88a7f Modified Files -------------- src/backend/access/gist/gistget.c | 4 ++++ src/backend/access/gist/gistscan.c | 8 ++++++++ 2 files changed, 12 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: GiST: Invalidate killed items consistently. @ 2026-08-19 19:46 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-19 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org GiST: Invalidate killed items consistently. GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5ce645173e6d4f90bccce1373f54879665166b6c Modified Files -------------- src/backend/access/gist/gistget.c | 4 ++++ src/backend/access/gist/gistscan.c | 8 ++++++++ 2 files changed, 12 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: GiST: Invalidate killed items consistently. @ 2026-08-19 19:46 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-19 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org GiST: Invalidate killed items consistently. GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/cb217c4f174f487009bcba3812bbf23b8d8eba4c Modified Files -------------- src/backend/access/gist/gistget.c | 44 ++++++++++++++++++++++---------------- src/backend/access/gist/gistscan.c | 10 +++++++++ src/include/access/gist_private.h | 1 + 3 files changed, 36 insertions(+), 19 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: GiST: Invalidate killed items consistently. @ 2026-08-19 19:46 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-19 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org GiST: Invalidate killed items consistently. GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d316899e1436e4d0268f596f405f9cdeb9cbc1b9 Modified Files -------------- src/backend/access/gist/gistget.c | 4 ++++ src/backend/access/gist/gistscan.c | 8 ++++++++ 2 files changed, 12 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: GiST: Invalidate killed items consistently. @ 2026-08-19 19:46 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-19 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org GiST: Invalidate killed items consistently. GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9628f4de6c5fadc73fa424f5a2e215b9aaa122cd Modified Files -------------- src/backend/access/gist/gistget.c | 4 ++++ src/backend/access/gist/gistscan.c | 8 ++++++++ 2 files changed, 12 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-08-19 19:46 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-19 19:46 pgsql: GiST: Invalidate killed items consistently. Peter Geoghegan <pg@bowt.ie> 2026-08-19 19:46 pgsql: GiST: Invalidate killed items consistently. Peter Geoghegan <pg@bowt.ie> 2026-08-19 19:46 pgsql: GiST: Invalidate killed items consistently. Peter Geoghegan <pg@bowt.ie> 2026-08-19 19:46 pgsql: GiST: Invalidate killed items consistently. Peter Geoghegan <pg@bowt.ie> 2026-08-19 19:46 pgsql: GiST: Invalidate killed items consistently. Peter Geoghegan <pg@bowt.ie> 2026-08-19 19:46 pgsql: GiST: Invalidate killed items consistently. Peter Geoghegan <pg@bowt.ie> 2026-08-19 19:46 pgsql: GiST: Invalidate killed items consistently. 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