pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page 6+ messages / 1 participants [nested] [flat]
* pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page @ 2025-01-25 19:29 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2025-01-25 19:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org At update of non-LP_NORMAL TID, fail instead of corrupting page header. The right mix of DDL and VACUUM could corrupt a catalog page header such that PageIsVerified() durably fails, requiring a restore from backup. This affects only catalogs that both have a syscache and have DDL code that uses syscache tuples to construct updates. One of the test permutations shows a variant not yet fixed. This makes !TransactionIdIsValid(TM_FailureData.xmax) possible with TM_Deleted. I think core and PGXN are indifferent to that. Per bug #17821 from Alexander Lakhin. Back-patch to v13 (all supported versions). The test case is v17+, since it uses INJECTION_POINT. Discussion: https://postgr.es/m/17821-dd8c334263399284@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8bfd2cebab0adc6e8dd86c5d34462eea247f0bb6 Modified Files -------------- src/backend/access/heap/heapam.c | 45 +++++++++++++++++++++++++++++++++++++++- src/include/access/tableam.h | 3 ++- 2 files changed, 46 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page @ 2025-01-25 19:29 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2025-01-25 19:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org At update of non-LP_NORMAL TID, fail instead of corrupting page header. The right mix of DDL and VACUUM could corrupt a catalog page header such that PageIsVerified() durably fails, requiring a restore from backup. This affects only catalogs that both have a syscache and have DDL code that uses syscache tuples to construct updates. One of the test permutations shows a variant not yet fixed. This makes !TransactionIdIsValid(TM_FailureData.xmax) possible with TM_Deleted. I think core and PGXN are indifferent to that. Per bug #17821 from Alexander Lakhin. Back-patch to v13 (all supported versions). The test case is v17+, since it uses INJECTION_POINT. Discussion: https://postgr.es/m/17821-dd8c334263399284@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9311fcb8648075782f59d534010352264bf8dc54 Modified Files -------------- src/backend/access/heap/heapam.c | 47 +++++++++++++++++++++++++++++++++++++++- src/include/access/tableam.h | 3 ++- 2 files changed, 48 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page @ 2025-01-25 19:29 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2025-01-25 19:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org At update of non-LP_NORMAL TID, fail instead of corrupting page header. The right mix of DDL and VACUUM could corrupt a catalog page header such that PageIsVerified() durably fails, requiring a restore from backup. This affects only catalogs that both have a syscache and have DDL code that uses syscache tuples to construct updates. One of the test permutations shows a variant not yet fixed. This makes !TransactionIdIsValid(TM_FailureData.xmax) possible with TM_Deleted. I think core and PGXN are indifferent to that. Per bug #17821 from Alexander Lakhin. Back-patch to v13 (all supported versions). The test case is v17+, since it uses INJECTION_POINT. Discussion: https://postgr.es/m/17821-dd8c334263399284@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/25e99483c4116313b678cc94df53d3ea28977752 Modified Files -------------- src/backend/access/heap/heapam.c | 45 +++++++++++++++++++++++++++++++++++++++- src/include/access/tableam.h | 3 ++- 2 files changed, 46 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page @ 2025-01-25 19:29 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2025-01-25 19:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org At update of non-LP_NORMAL TID, fail instead of corrupting page header. The right mix of DDL and VACUUM could corrupt a catalog page header such that PageIsVerified() durably fails, requiring a restore from backup. This affects only catalogs that both have a syscache and have DDL code that uses syscache tuples to construct updates. One of the test permutations shows a variant not yet fixed. This makes !TransactionIdIsValid(TM_FailureData.xmax) possible with TM_Deleted. I think core and PGXN are indifferent to that. Per bug #17821 from Alexander Lakhin. Back-patch to v13 (all supported versions). The test case is v17+, since it uses INJECTION_POINT. Discussion: https://postgr.es/m/17821-dd8c334263399284@postgresql.org Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f4af4515bb5f3591d49bc16b6cb8ddbf66f98374 Modified Files -------------- src/backend/access/heap/heapam.c | 49 +++++- src/backend/utils/cache/inval.c | 3 + src/include/access/tableam.h | 3 +- src/test/modules/injection_points/Makefile | 9 +- .../expected/syscache-update-pruned.out | 87 ++++++++++ .../expected/syscache-update-pruned_1.out | 86 ++++++++++ .../injection_points/injection_points--1.0.sql | 8 + src/test/modules/injection_points/meson.build | 4 +- .../modules/injection_points/regress_injection.c | 71 ++++++++ .../specs/syscache-update-pruned.spec | 179 +++++++++++++++++++++ 10 files changed, 493 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page @ 2025-01-25 19:29 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2025-01-25 19:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org At update of non-LP_NORMAL TID, fail instead of corrupting page header. The right mix of DDL and VACUUM could corrupt a catalog page header such that PageIsVerified() durably fails, requiring a restore from backup. This affects only catalogs that both have a syscache and have DDL code that uses syscache tuples to construct updates. One of the test permutations shows a variant not yet fixed. This makes !TransactionIdIsValid(TM_FailureData.xmax) possible with TM_Deleted. I think core and PGXN are indifferent to that. Per bug #17821 from Alexander Lakhin. Back-patch to v13 (all supported versions). The test case is v17+, since it uses INJECTION_POINT. Discussion: https://postgr.es/m/17821-dd8c334263399284@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dc02b98bd1c8d653370fd8828063b1aee0b5b9eb Modified Files -------------- src/backend/access/heap/heapam.c | 45 +++++++++++++++++++++++++++++++++++++++- src/include/access/tableam.h | 3 ++- 2 files changed, 46 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page @ 2025-01-25 19:29 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2025-01-25 19:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org At update of non-LP_NORMAL TID, fail instead of corrupting page header. The right mix of DDL and VACUUM could corrupt a catalog page header such that PageIsVerified() durably fails, requiring a restore from backup. This affects only catalogs that both have a syscache and have DDL code that uses syscache tuples to construct updates. One of the test permutations shows a variant not yet fixed. This makes !TransactionIdIsValid(TM_FailureData.xmax) possible with TM_Deleted. I think core and PGXN are indifferent to that. Per bug #17821 from Alexander Lakhin. Back-patch to v13 (all supported versions). The test case is v17+, since it uses INJECTION_POINT. Discussion: https://postgr.es/m/17821-dd8c334263399284@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d28cd3e7b21c41a710fd9c188a57dad99f28805f Modified Files -------------- src/backend/access/heap/heapam.c | 49 +++++- src/backend/utils/cache/inval.c | 3 + src/include/access/tableam.h | 3 +- src/test/modules/injection_points/Makefile | 5 +- .../expected/syscache-update-pruned.out | 87 ++++++++++ .../expected/syscache-update-pruned_1.out | 86 ++++++++++ .../injection_points/injection_points--1.0.sql | 8 + src/test/modules/injection_points/meson.build | 4 +- .../modules/injection_points/regress_injection.c | 71 ++++++++ .../specs/syscache-update-pruned.spec | 179 +++++++++++++++++++++ 10 files changed, 490 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-01-25 19:29 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-01-25 19:29 pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page Noah Misch <noah@leadboat.com> 2025-01-25 19:29 pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page Noah Misch <noah@leadboat.com> 2025-01-25 19:29 pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page Noah Misch <noah@leadboat.com> 2025-01-25 19:29 pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page Noah Misch <noah@leadboat.com> 2025-01-25 19:29 pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page Noah Misch <noah@leadboat.com> 2025-01-25 19:29 pgsql: At update of non-LP_NORMAL TID, fail instead of corrupting page Noah Misch <noah@leadboat.com>
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