Commit e27453b
committed
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.us1 parent a6949ca commit e27453b
1 file changed
+14
-4
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
9888 | 9888 | | |
9889 | 9889 | | |
9890 | 9890 | | |
9891 | | - | |
9892 | | - | |
| 9891 | + | |
9893 | 9892 | | |
9894 | 9893 | | |
9895 | 9894 | | |
| |||
9905 | 9904 | | |
9906 | 9905 | | |
9907 | 9906 | | |
| 9907 | + | |
9908 | 9908 | | |
9909 | 9909 | | |
9910 | 9910 | | |
| |||
9921 | 9921 | | |
9922 | 9922 | | |
9923 | 9923 | | |
| 9924 | + | |
9924 | 9925 | | |
9925 | 9926 | | |
9926 | 9927 | | |
9927 | | - | |
| 9928 | + | |
9928 | 9929 | | |
9929 | 9930 | | |
9930 | 9931 | | |
| |||
9936 | 9937 | | |
9937 | 9938 | | |
9938 | 9939 | | |
| 9940 | + | |
| 9941 | + | |
| 9942 | + | |
| 9943 | + | |
| 9944 | + | |
| 9945 | + | |
| 9946 | + | |
| 9947 | + | |
| 9948 | + | |
9939 | 9949 | | |
9940 | 9950 | | |
9941 | 9951 | | |
| |||
9951 | 9961 | | |
9952 | 9962 | | |
9953 | 9963 | | |
9954 | | - | |
| 9964 | + | |
9955 | 9965 | | |
9956 | 9966 | | |
9957 | 9967 | | |
| |||
0 commit comments