Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit0360c53

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 constraintof another table, ALTER TABLE would open the other table (to re-parsethe 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 forcatalog reads, but even in current releases it doesn't seem like a goodidea.We know we'll need AccessExclusiveLock shortly to drop the obsoletedconstraint, so just get that a little sooner to close the hole.Per testing with a patch that complains if we open a relation withoutholding any lock on it. I don't plan to back-patch that patch, but weshould close the holes it identifies in all supported branches.Discussion:https://postgr.es/m/2038.1538335244@sss.pgh.pa.us
1 parent2855421 commit0360c53

File tree

1 file changed

+12
-2
lines changed

1 file changed

+12
-2
lines changed

‎src/backend/commands/tablecmds.c

Lines changed: 12 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8686,8 +8686,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
86868686
* appropriate work queue entries. We do this before dropping because in
86878687
* the case of a FOREIGN KEY constraint, we might not yet have exclusive
86888688
* lock on the table the constraint is attached to, and we need to get
8689-
* that before dropping. It's safe because the parser won't actually look
8690-
* at the catalogs to detect the existing entry.
8689+
* that before reparsing/dropping.
86918690
*
86928691
* We can't rely on the output of deparsing to tell us which relation to
86938692
* operate on, because concurrent activity might have made the name
@@ -8703,6 +8702,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
87038702
Form_pg_constraintcon;
87048703
Oidrelid;
87058704
Oidconfrelid;
8705+
charcontype;
87068706
boolconislocal;
87078707

87088708
tup=SearchSysCache1(CONSTROID,ObjectIdGetDatum(oldId));
@@ -8711,6 +8711,7 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
87118711
con= (Form_pg_constraint)GETSTRUCT(tup);
87128712
relid=con->conrelid;
87138713
confrelid=con->confrelid;
8714+
contype=con->contype;
87148715
conislocal=con->conislocal;
87158716
ReleaseSysCache(tup);
87168717

@@ -8723,6 +8724,15 @@ ATPostAlterTypeCleanup(List **wqueue, AlteredTableInfo *tab, LOCKMODE lockmode)
87238724
if (!conislocal)
87248725
continue;
87258726

8727+
/*
8728+
* When rebuilding an FK constraint that references the table we're
8729+
* modifying, we might not yet have any lock on the FK's table, so get
8730+
* one now. We'll need AccessExclusiveLock for the DROP CONSTRAINT
8731+
* step, so there's no value in asking for anything weaker.
8732+
*/
8733+
if (relid!=tab->relid&&contype==CONSTRAINT_FOREIGN)
8734+
LockRelationOid(relid,AccessExclusiveLock);
8735+
87268736
ATPostAlterTypeParse(oldId,relid,confrelid,
87278737
(char*)lfirst(def_item),
87288738
wqueue,lockmode,tab->rewrite);

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp