]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix some more bugs in foreign keys connecting partitioned tables
authorÁlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 30 Oct 2024 09:54:03 +0000 (10:54 +0100)
committerÁlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 30 Oct 2024 09:54:03 +0000 (10:54 +0100)
commit1b216fceffe3e4858b4e1e58427534e115f27547
tree6f5b2704e06b3325f1846553a89f61582bd2441b
parent0fe002d0c9a5b04bb676e9cb8f80325f7129b5f3
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
src/backend/commands/tablecmds.c
src/test/regress/expected/foreign_key.out
src/test/regress/sql/foreign_key.sql