diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-10-01 11:39:13 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-10-01 11:39:13 -0400 |
| commit | 4c985549fe82c2a283f5f113747ae2ffd1a95926 (patch) | |
| tree | cc3e431ecc5d5668d6dc714f9ef6a0676caa8eb9 /contrib/jsonb_plpython/jsonb_plpython2u.control | |
| parent | 7871a36255e2675075990714bfe0d051f3807efc (diff) | |
| download | postgresql-4c985549fe82c2a283f5f113747ae2ffd1a95926.tar.gz postgresql-4c985549fe82c2a283f5f113747ae2ffd1a95926.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 'contrib/jsonb_plpython/jsonb_plpython2u.control')
0 files changed, 0 insertions, 0 deletions