From fd93ee100830a1c0f4d292addd0a460cb48106a0 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Wed, 27 May 2026 18:35:55 +0300 Subject: [PATCH] Don't try to record dependency on a dropped column's datatype When creating a relation with a dropped column, we called recordDependencyOn() also on the datatype of the dropped column, which is always InvalidOid. In versions 15 and above, that was harmless because recordDependencyOn() considers InvalidOid as a pinned object, and skips over it. On version 14, isPinnedObject() does not consider InvalidOid as pinned, so we created a bogus pg_depend entry with refobjectid == 0. As far as I can tell, the only case when AddNewAttributeTuples() is called with dropped columns is when performing a table-rewriting ALTER TABLE command. That temporarily creates a new relation with the same columns, including dropped ones, then swaps the relations, and drops the newly created table again. So even on version 14, the bogus pg_depend entry was only on the transient relation that was dropped at the end of the ALTER TABLE command, which was harmless. Even though this is harmless, let's be tidy, similar to commit 713bce9484. The reason I noticed this now and why I backported this, is because the next commit will add code to acquire locks on the referenced objects, and we don't want to acquire a lock on InvalidOid. Discussion: https://postgr.es/m/ZiYjn0eVc7pxVY45@ip-10-97-1-34.eu-west-3.compute.internal Backpatch-through: 14 --- src/backend/catalog/heap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c index 4f6b00bd739..88087654de9 100644 --- a/src/backend/catalog/heap.c +++ b/src/backend/catalog/heap.c @@ -870,6 +870,9 @@ AddNewAttributeTuples(Oid new_rel_oid, { Form_pg_attribute attr = TupleDescAttr(tupdesc, i); + if (attr->attisdropped) + continue; + /* Add dependency info */ ObjectAddressSubSet(myself, RelationRelationId, new_rel_oid, i + 1); ObjectAddressSet(referenced, TypeRelationId, attr->atttypid);