]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Obtain required table lock during cross-table constraint updates.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 29 Jun 2025 17:56:03 +0000 (13:56 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 29 Jun 2025 17:56:03 +0000 (13:56 -0400)
commitbbfcbc4cde4a9fb5b1d91acc3d8efc6f868c2684
tree7bd78a626ac49e9e6eaca0e1cc1ae5bb1f52e55e
parent07402e370e5b07d342a74025407f37a38fe9f064
Obtain required table lock during cross-table constraint updates.

Sometimes a table's constraint may depend on a column of another
table, so that we have to update the constraint when changing the
referenced column's type.  We need to have lock on the constraint's
table to do that.  ATPostAlterTypeCleanup believed that this case
was only possible for FOREIGN KEY constraints, but it's wrong at
least for CHECK and EXCLUDE constraints; and in general, we'd
probably need exclusive lock to alter any sort of constraint.
So just remove the contype check and acquire lock for any other
table.  This prevents a "you don't have lock" assertion failure,
though no ill effect is observed in production builds.

We'll error out later anyway because we don't presently support
physically altering column types within stored composite columns.
But the catalog-munging is basically all there, so we may as well
make that part work.

Bug: #18970
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: jian he <jian.universality@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org
Backpatch-through: 13
src/backend/commands/tablecmds.c
src/test/regress/expected/alter_table.out
src/test/regress/sql/alter_table.sql