aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-04-02 14:59:04 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-04-02 14:59:04 -0400
commitcbfbb14bd7de9e90fb107cdcaa783264bf8fcdb9 (patch)
treebd48e7703dbaaaa0fa2e5ed643b02fe31a642061 /contrib/postgres_fdw/postgres_fdw.c
parent3235a11c128b5979bce84d56b8044c7fb2e6b61d (diff)
downloadpostgresql-cbfbb14bd7de9e90fb107cdcaa783264bf8fcdb9.tar.gz
postgresql-cbfbb14bd7de9e90fb107cdcaa783264bf8fcdb9.zip
Avoid deadlock during orphan temp table removal.
If temp tables have dependencies (such as sequences) then it's possible for autovacuum's cleanup of orphan temp tables to deadlock against an incoming backend that's trying to clean out the temp namespace for its own use. That can happen because RemoveTempRelations' performDeletion call can visit objects within the namespace in an order different from the order in which a per-table deletion will visit them. To fix, observe that performDeletion will begin by taking an exclusive lock on the temp namespace (even though it won't actually delete it). So, if we can get a shared lock on the namespace, we can be sure we're not running concurrently with RemoveTempRelations, while also not conflicting with ordinary use of the namespace. This requires introducing a conditional version of LockDatabaseObject, but that's no big deal. (It's surprising we've got along without that this long.) Report and patch by Mikhail Zhilin. Back-patch to all supported branches. Discussion: https://postgr.es/m/c43ce028-2bc2-4865-9b89-3f706246eed5@postgrespro.ru
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions