Fix concurrency issues with DROP TABLESPACE DROP TABLESPACE checked pg_shdepend for dependent objects without first locking the tablespace. A concurrent command that recorded a shared dependency on the tablespace right after that check could still commit, leaving an object whose pg_shdepend entry (or, for a relation, pg_class.reltablespace) pointed to a tablespace that no longer existed.
Close the race by having DropTableSpace() take an AccessExclusiveLock on the tablespace before calling checkSharedDependencies(). That conflicts with the AccessShareLock shdepLockAndCheckObject() takes when recording a new dependency, so the loser of the race blocks and rechecks once the winner commits. That AccessExclusiveLock creates a new deadlock: ALTER TABLESPACE RENAME/SET and the internal ACL/owner updates in DROP OWNED and REASSIGN OWNED touched the catalog tuple without locking the tablespace, risking a lock-order cycle with DROP. Fix by taking an AccessShareLock first in all four paths, rechecking pg_shdepend after any wait in the DROP OWNED and REASSIGN OWNED cases. GRANT, REVOKE, and ALTER TABLESPACE ... OWNER TO already lock the object. Add isolation tests covering both orderings of the original race (dependency-first and drop-first) and all four previously-unlocked update paths. Author: Ayush Tiwari <[email protected]> Reviewed-by: Andrew Dunstan <[email protected]> Discussion: https://postgr.es/m/cajtyswxjaqfngkzxsht3xk8khhyhontwfjw4jahsusfs_pt...@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5dec175fb4c537947faaba504cda394b4ca6b726 Modified Files -------------- src/backend/catalog/pg_shdepend.c | 40 +++++++-- src/backend/commands/tablespace.c | 16 +++- .../expected/tablespace-dependency-locking.out | 84 +++++++++++++++++++ src/test/isolation/isolation_schedule | 1 + .../specs/tablespace-dependency-locking.spec | 98 ++++++++++++++++++++++ 5 files changed, 232 insertions(+), 7 deletions(-)
