pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix some more bugs in foreign keys connecting partitioned tables 4+ messages / 1 participants [nested] [flat]
* pgsql: Fix some more bugs in foreign keys connecting partitioned tables @ 2024-10-30 10:29 Álvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 4+ messages in thread From: Álvaro Herrera @ 2024-10-30 10:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix some more bugs in foreign keys connecting partitioned tables * In DetachPartitionFinalize() we were applying a tuple conversion map to tuples that didn't need one, which can lead to erratic behavior if a partitioned table has a partition with a different column order, as reported by Alexander Lakhin. This was introduced by 53af9491a043. Don't do that. Also, modify a recently added test case to exercise this. * The same function as well as CloneFkReferenced() were acquiring AccessShareLock on a partition, only to have CreateTrigger() later acquire ShareRowExclusiveLock on it. This can lead to deadlock by lock escalation, unnecessarily. Avoid that by acquiring the stronger lock to begin with. This probably dates back to branch 12, but I have never seen a report of this being a problem in the field. * Innocuous but wasteful: also introduced by 53af9491a043, we were reading a pg_constraint tuple from syscache that we don't need, as reported by Tender Wang. Don't. Backpatch to 15. Discussion: https://postgr.es/m/461e9c26-2076-8224-e119-84998b6a784e@gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/2d5fe514052ad82e46612e4c572f1c999be56a71 Modified Files -------------- src/backend/commands/tablecmds.c | 38 ++++++++++++------------------- src/test/regress/expected/foreign_key.out | 9 +++++--- src/test/regress/sql/foreign_key.sql | 10 +++++--- 3 files changed, 27 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix some more bugs in foreign keys connecting partitioned tables @ 2024-10-30 10:29 Álvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 4+ messages in thread From: Álvaro Herrera @ 2024-10-30 10:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix some more bugs in foreign keys connecting partitioned tables * In DetachPartitionFinalize() we were applying a tuple conversion map to tuples that didn't need one, which can lead to erratic behavior if a partitioned table has a partition with a different column order, as reported by Alexander Lakhin. This was introduced by 53af9491a043. Don't do that. Also, modify a recently added test case to exercise this. * The same function as well as CloneFkReferenced() were acquiring AccessShareLock on a partition, only to have CreateTrigger() later acquire ShareRowExclusiveLock on it. This can lead to deadlock by lock escalation, unnecessarily. Avoid that by acquiring the stronger lock to begin with. This probably dates back to branch 12, but I have never seen a report of this being a problem in the field. * Innocuous but wasteful: also introduced by 53af9491a043, we were reading a pg_constraint tuple from syscache that we don't need, as reported by Tender Wang. Don't. Backpatch to 15. Discussion: https://postgr.es/m/461e9c26-2076-8224-e119-84998b6a784e@gmail.com Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f7d510a382451d4f29a3bbc97a98a6b0061ea0b6 Modified Files -------------- src/backend/commands/tablecmds.c | 38 ++++++++++++------------------- src/test/regress/expected/foreign_key.out | 9 +++++--- src/test/regress/sql/foreign_key.sql | 10 +++++--- 3 files changed, 27 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix some more bugs in foreign keys connecting partitioned tables @ 2024-10-30 10:29 Álvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 4+ messages in thread From: Álvaro Herrera @ 2024-10-30 10:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix some more bugs in foreign keys connecting partitioned tables * In DetachPartitionFinalize() we were applying a tuple conversion map to tuples that didn't need one, which can lead to erratic behavior if a partitioned table has a partition with a different column order, as reported by Alexander Lakhin. This was introduced by 53af9491a043. Don't do that. Also, modify a recently added test case to exercise this. * The same function as well as CloneFkReferenced() were acquiring AccessShareLock on a partition, only to have CreateTrigger() later acquire ShareRowExclusiveLock on it. This can lead to deadlock by lock escalation, unnecessarily. Avoid that by acquiring the stronger lock to begin with. This probably dates back to branch 12, but I have never seen a report of this being a problem in the field. * Innocuous but wasteful: also introduced by 53af9491a043, we were reading a pg_constraint tuple from syscache that we don't need, as reported by Tender Wang. Don't. Backpatch to 15. Discussion: https://postgr.es/m/461e9c26-2076-8224-e119-84998b6a784e@gmail.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1b216fceffe3e4858b4e1e58427534e115f27547 Modified Files -------------- src/backend/commands/tablecmds.c | 39 ++++++++++++------------------- src/test/regress/expected/foreign_key.out | 9 ++++--- src/test/regress/sql/foreign_key.sql | 10 +++++--- 3 files changed, 28 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix some more bugs in foreign keys connecting partitioned tables @ 2024-10-30 10:29 Álvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 4+ messages in thread From: Álvaro Herrera @ 2024-10-30 10:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix some more bugs in foreign keys connecting partitioned tables * In DetachPartitionFinalize() we were applying a tuple conversion map to tuples that didn't need one, which can lead to erratic behavior if a partitioned table has a partition with a different column order, as reported by Alexander Lakhin. This was introduced by 53af9491a043. Don't do that. Also, modify a recently added test case to exercise this. * The same function as well as CloneFkReferenced() were acquiring AccessShareLock on a partition, only to have CreateTrigger() later acquire ShareRowExclusiveLock on it. This can lead to deadlock by lock escalation, unnecessarily. Avoid that by acquiring the stronger lock to begin with. This probably dates back to branch 12, but I have never seen a report of this being a problem in the field. * Innocuous but wasteful: also introduced by 53af9491a043, we were reading a pg_constraint tuple from syscache that we don't need, as reported by Tender Wang. Don't. Backpatch to 15. Discussion: https://postgr.es/m/461e9c26-2076-8224-e119-84998b6a784e@gmail.com Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/936ab6de95957e1c407ce9dfdc38c54ad146eb5d Modified Files -------------- src/backend/commands/tablecmds.c | 38 ++++++++++++------------------- src/test/regress/expected/foreign_key.out | 9 +++++--- src/test/regress/sql/foreign_key.sql | 10 +++++--- 3 files changed, 27 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-10-30 10:29 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-10-30 10:29 pgsql: Fix some more bugs in foreign keys connecting partitioned tables Álvaro Herrera <alvherre@alvh.no-ip.org> 2024-10-30 10:29 pgsql: Fix some more bugs in foreign keys connecting partitioned tables Álvaro Herrera <alvherre@alvh.no-ip.org> 2024-10-30 10:29 pgsql: Fix some more bugs in foreign keys connecting partitioned tables Álvaro Herrera <alvherre@alvh.no-ip.org> 2024-10-30 10:29 pgsql: Fix some more bugs in foreign keys connecting partitioned tables Álvaro Herrera <alvherre@alvh.no-ip.org>
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