pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix snapshot import xmin ProcArrayLock bug. 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix snapshot import xmin ProcArrayLock bug. @ 2026-08-20 23:48 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-20 23:48 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix snapshot import xmin ProcArrayLock bug. ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/0ebeec35fc3c3bf617ac447b36f1b158b076f6e7 Modified Files -------------- src/backend/storage/ipc/procarray.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix snapshot import xmin ProcArrayLock bug. @ 2026-08-20 23:48 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-20 23:48 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix snapshot import xmin ProcArrayLock bug. ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ca99016f939dc1e1b260c3ea16721948a1558ef7 Modified Files -------------- src/backend/storage/ipc/procarray.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix snapshot import xmin ProcArrayLock bug. @ 2026-08-20 23:48 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-20 23:48 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix snapshot import xmin ProcArrayLock bug. ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3977cde272bc38d33d73bc8c9ff5c1156fb95342 Modified Files -------------- src/backend/storage/ipc/procarray.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix snapshot import xmin ProcArrayLock bug. @ 2026-08-20 23:48 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-20 23:48 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix snapshot import xmin ProcArrayLock bug. ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/24bf23fe665f265328cc6ff82a5a5d5faab2b3bd Modified Files -------------- src/backend/storage/ipc/procarray.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix snapshot import xmin ProcArrayLock bug. @ 2026-08-20 23:48 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-20 23:48 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix snapshot import xmin ProcArrayLock bug. ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7a392b0f6530236b71f15c936ba3f813c0720897 Modified Files -------------- src/backend/storage/ipc/procarray.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix snapshot import xmin ProcArrayLock bug. @ 2026-08-20 23:48 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-20 23:48 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix snapshot import xmin ProcArrayLock bug. ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4afe4b564d867c0a2752840a309dfe5fb2616c6e Modified Files -------------- src/backend/storage/ipc/procarray.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix snapshot import xmin ProcArrayLock bug. @ 2026-08-20 23:48 Peter Geoghegan <pg@bowt.ie> 0 siblings, 0 replies; 7+ messages in thread From: Peter Geoghegan @ 2026-08-20 23:48 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix snapshot import xmin ProcArrayLock bug. ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e94ba903bc3e3432ee78150e8e15c37bffe1328d Modified Files -------------- src/backend/storage/ipc/procarray.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-08-20 23:48 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-20 23:48 pgsql: Fix snapshot import xmin ProcArrayLock bug. Peter Geoghegan <pg@bowt.ie> 2026-08-20 23:48 pgsql: Fix snapshot import xmin ProcArrayLock bug. Peter Geoghegan <pg@bowt.ie> 2026-08-20 23:48 pgsql: Fix snapshot import xmin ProcArrayLock bug. Peter Geoghegan <pg@bowt.ie> 2026-08-20 23:48 pgsql: Fix snapshot import xmin ProcArrayLock bug. Peter Geoghegan <pg@bowt.ie> 2026-08-20 23:48 pgsql: Fix snapshot import xmin ProcArrayLock bug. Peter Geoghegan <pg@bowt.ie> 2026-08-20 23:48 pgsql: Fix snapshot import xmin ProcArrayLock bug. Peter Geoghegan <pg@bowt.ie> 2026-08-20 23:48 pgsql: Fix snapshot import xmin ProcArrayLock 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