agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix crash on UPDATE or DELETE of a partition pending detach. 2+ messages / 1 participants [nested] [flat]
* pgsql: Fix crash on UPDATE or DELETE of a partition pending detach. @ 2026-09-11 09:57 Amit Kapila <akapila@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Amit Kapila @ 2026-09-11 09:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix crash on UPDATE or DELETE of a partition pending detach. ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY leaves the partition marked as detach-pending if its wait is interrupted, and only DETACH PARTITION ... FINALIZE clears that mark. In that state pg_class still says relispartition while get_partition_ancestors() already reports nothing, which RelationBuildPublicationDesc() was not ready for. It took relispartition to mean that the ancestor list is not empty and asked for its last element, which is an assertion failure, or a NULL pointer dereference without assertions. CheckCmdReplicaIdentity() needs the descriptor for every UPDATE and DELETE of a publishable relation and builds it on first use, so no publication has to exist for this, and a plain UPDATE crashes the backend. Treat such a partition as a standalone table, as after the detach is finalized. It is then published by FOR ALL TABLES publications, but cannot be added to an EXCEPT clause until the detach completes, which is now reported with a hint to run DETACH PARTITION ... FINALIZE. Oversight in fd366065e06a, which added the exclusion. Author: Mikhail Nikalayeu <mihailnikalayeu@gmail.com> Author: shveta malik <shveta.malik@gmail.com> Author: Nisha Moond <nisha.moond412@gmail.com> Reviewed-by: shveta malik <shveta.malik@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Reviewed-by: Nisha Moond <nisha.moond412@gmail.com> Discussion: https://postgr.es/m/CADzfLwWoFPT%2Ba73%3DA%3DbsNWRMZQ98NpBEMgE%3Dt1FS4O4_%3DQVLfA%40mail.gmail.com Backpatch-through: 19, where it was introduced Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/479a931155c6758831e57ba76f9671565c1e5553 Modified Files -------------- src/backend/catalog/pg_publication.c | 9 ++++++++ src/backend/utils/cache/relcache.c | 10 ++++++++- .../expected/detach-partition-concurrently-3.out | 25 ++++++++++++++++++++++ .../specs/detach-partition-concurrently-3.spec | 10 +++++++++ 4 files changed, 53 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Fix crash on UPDATE or DELETE of a partition pending detach. @ 2026-09-11 09:57 Amit Kapila <akapila@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Amit Kapila @ 2026-09-11 09:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix crash on UPDATE or DELETE of a partition pending detach. ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY leaves the partition marked as detach-pending if its wait is interrupted, and only DETACH PARTITION ... FINALIZE clears that mark. In that state pg_class still says relispartition while get_partition_ancestors() already reports nothing, which RelationBuildPublicationDesc() was not ready for. It took relispartition to mean that the ancestor list is not empty and asked for its last element, which is an assertion failure, or a NULL pointer dereference without assertions. CheckCmdReplicaIdentity() needs the descriptor for every UPDATE and DELETE of a publishable relation and builds it on first use, so no publication has to exist for this, and a plain UPDATE crashes the backend. Treat such a partition as a standalone table, as after the detach is finalized. It is then published by FOR ALL TABLES publications, but cannot be added to an EXCEPT clause until the detach completes, which is now reported with a hint to run DETACH PARTITION ... FINALIZE. Oversight in fd366065e06a, which added the exclusion. Author: Mikhail Nikalayeu <mihailnikalayeu@gmail.com> Author: shveta malik <shveta.malik@gmail.com> Author: Nisha Moond <nisha.moond412@gmail.com> Reviewed-by: shveta malik <shveta.malik@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Reviewed-by: Nisha Moond <nisha.moond412@gmail.com> Discussion: https://postgr.es/m/CADzfLwWoFPT%2Ba73%3DA%3DbsNWRMZQ98NpBEMgE%3Dt1FS4O4_%3DQVLfA%40mail.gmail.com Backpatch-through: 19, where it was introduced Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/090b44557d45686403d2d98c32d1d3add4337361 Modified Files -------------- src/backend/catalog/pg_publication.c | 9 ++++++++ src/backend/utils/cache/relcache.c | 10 ++++++++- .../expected/detach-partition-concurrently-3.out | 25 ++++++++++++++++++++++ .../specs/detach-partition-concurrently-3.spec | 10 +++++++++ 4 files changed, 53 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-09-11 09:57 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-09-11 09:57 pgsql: Fix crash on UPDATE or DELETE of a partition pending detach. Amit Kapila <akapila@postgresql.org> 2026-09-11 09:57 pgsql: Fix crash on UPDATE or DELETE of a partition pending detach. Amit Kapila <akapila@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox