Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 4c98554

Browse files
committed
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint of another table, ALTER TABLE would open the other table (to re-parse the constraint's definition) without having first obtained a lock on it. This was evidently intentional, but that doesn't mean it's really safe. It's especially not safe in 9.3, which pre-dates use of MVCC scans for catalog reads, but even in current releases it doesn't seem like a good idea. We know we'll need AccessExclusiveLock shortly to drop the obsoleted constraint, so just get that a little sooner to close the hole. Per testing with a patch that complains if we open a relation without holding any lock on it. I don't plan to back-patch that patch, but we should close the holes it identifies in all supported branches. Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us
1 parent 7871a36 commit 4c98554

File tree

1 file changed

+14
-4
lines changed

1 file changed

+14
-4
lines changed

src/backend/commands/tablecmds.c

Lines changed: 14 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -9857,8 +9857,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
98579857
* appropriate work queue entries. We do this before dropping because in
98589858
* the case of a FOREIGN KEY constraint, we might not yet have exclusive
98599859
* lock on the table the constraint is attached to, and we need to get
9860-
* that before dropping. It's safe because the parser won't actually look
9861-
* at the catalogs to detect the existing entry.
9860+
* that before reparsing/dropping.
98629861
*
98639862
* We can't rely on the output of deparsing to tell us which relation to
98649863
* operate on, because concurrent activity might have made the name
@@ -9874,6 +9873,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
98749873
Form_pg_constraint con;
98759874
Oid relid;
98769875
Oid confrelid;
9876+
char contype;
98779877
bool conislocal;
98789878

98799879
tup = SearchSysCache1(CONSTROID, ObjectIdGetDatum(oldId));
@@ -9890,10 +9890,11 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
98909890
elog(ERROR, "could not identify relation associated with constraint %u", oldId);
98919891
}
98929892
confrelid = con->confrelid;
9893+
contype = con->contype;
98939894
conislocal = con->conislocal;
98949895
ReleaseSysCache(tup);
98959896

9896-
ObjectAddressSet(obj, ConstraintRelationId, lfirst_oid(oid_item));
9897+
ObjectAddressSet(obj, ConstraintRelationId, oldId);
98979898
add_exact_object_address(&obj, objects);
98989899

98999900
/*
@@ -9905,6 +9906,15 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
99059906
if (!conislocal)
99069907
continue;
99079908

9909+
/*
9910+
* When rebuilding an FK constraint that references the table we're
9911+
* modifying, we might not yet have any lock on the FK's table, so get
9912+
* one now. We'll need AccessExclusiveLock for the DROP CONSTRAINT
9913+
* step, so there's no value in asking for anything weaker.
9914+
*/
9915+
if (relid != tab->relid && contype == CONSTRAINT_FOREIGN)
9916+
LockRelationOid(relid, AccessExclusiveLock);
9917+
99089918
ATPostAlterTypeParse(oldId, relid, confrelid,
99099919
(char *) lfirst(def_item),
99109920
wqueue, lockmode, tab->rewrite);
@@ -9920,7 +9930,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
99209930
(char *) lfirst(def_item),
99219931
wqueue, lockmode, tab->rewrite);
99229932

9923-
ObjectAddressSet(obj, RelationRelationId, lfirst_oid(oid_item));
9933+
ObjectAddressSet(obj, RelationRelationId, oldId);
99249934
add_exact_object_address(&obj, objects);
99259935
}
99269936

0 commit comments

Comments
 (0)