From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Fix ALTER COLUMN TYPE to not open a relation without any lock. |
Date: | 2018-10-01 15:51:33 |
Message-ID: | E1g70Tt-00044n-OK@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e27453bd839f3d0f55f94afa554be7066a841ab3
Modified Files
--------------
src/backend/commands/tablecmds.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-10-01 16:43:34 | pgsql: Add assertions that we hold some relevant lock during relation o |
Previous Message | Peter Eisentraut | 2018-10-01 12:13:47 | pgsql: doc: Clarify CREATE TABLESPACE documentation |