aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-10-01 11:39:13 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-10-01 11:39:13 -0400
commite27453bd839f3d0f55f94afa554be7066a841ab3 (patch)
treefed8321c5a54cbe837b6614f021cb5055256ea7d /src/backend/executor/nodeModifyTable.c
parenta6949ca34d3aca018870815cf6cb690024aeea04 (diff)
downloadpostgresql-e27453bd839f3d0f55f94afa554be7066a841ab3.tar.gz
postgresql-e27453bd839f3d0f55f94afa554be7066a841ab3.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/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions