aboutsummaryrefslogtreecommitdiff
path: root/src/backend
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-10-01 11:39:14 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-10-01 11:39:14 -0400
commitdb01fc97ad80e6e29dd5a2d5736cfd3e484f9a30 (patch)
tree8f1121b0b42975c3b4ceefeb425be8bfe073da4f /src/backend
parent0aa1e0ef167d05a9ec66958b8784d72becf9303d (diff)
downloadpostgresql-db01fc97ad80e6e29dd5a2d5736cfd3e484f9a30.tar.gz
postgresql-db01fc97ad80e6e29dd5a2d5736cfd3e484f9a30.zip
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
Diffstat (limited to 'src/backend')
-rw-r--r--src/backend/commands/tablecmds.c14
1 files changed, 12 insertions, 2 deletions
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index d9187a86c0e..f143101b5dc 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -9513,8 +9513,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
* appropriate work queue entries. We do this before dropping because in
* the case of a FOREIGN KEY constraint, we might not yet have exclusive
* lock on the table the constraint is attached to, and we need to get
- * that before dropping. It's safe because the parser won't actually look
- * at the catalogs to detect the existing entry.
+ * that before reparsing/dropping.
*
* We can't rely on the output of deparsing to tell us which relation to
* operate on, because concurrent activity might have made the name
@@ -9530,6 +9529,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
Form_pg_constraint con;
Oid relid;
Oid confrelid;
+ char contype;
bool conislocal;
tup = SearchSysCache1(CONSTROID, ObjectIdGetDatum(oldId));
@@ -9538,6 +9538,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
con = (Form_pg_constraint) GETSTRUCT(tup);
relid = con->conrelid;
confrelid = con->confrelid;
+ contype = con->contype;
conislocal = con->conislocal;
ReleaseSysCache(tup);
@@ -9550,6 +9551,15 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
if (!conislocal)
continue;
+ /*
+ * When rebuilding an FK constraint that references the table we're
+ * modifying, we might not yet have any lock on the FK's table, so get
+ * one now. We'll need AccessExclusiveLock for the DROP CONSTRAINT
+ * step, so there's no value in asking for anything weaker.
+ */
+ if (relid != tab->relid && contype == CONSTRAINT_FOREIGN)
+ LockRelationOid(relid, AccessExclusiveLock);
+
ATPostAlterTypeParse(oldId, relid, confrelid,
(char *) lfirst(def_item),
wqueue, lockmode, tab->rewrite);