You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Fix unsafe order of operations in foreign-table DDL commands.
When updating or deleting a system catalog tuple, it's necessary to acquireRowExclusiveLock on the catalog before looking up the tuple; otherwise aconcurrent VACUUM FULL on the catalog might move the tuple to a differentTID before we can apply the update. Coding patterns that find the tuplevia a table scan aren't at risk here, but when obtaining the tuple from acatalog cache, correct ordering is important; and several routines inforeigncmds.c got it wrong. Noted while running the regression tests inparallel with VACUUM FULL of assorted system catalogs.For consistency I moved all the heap_open calls to the starts of theirfunctions, including a couple for which there was no actual bug.Back-patch to 8.4 where foreigncmds.c was added.