pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Avoid deadlock during orphan temp table removal. 6+ messages / 1 participants [nested] [flat]
* pgsql: Avoid deadlock during orphan temp table removal. @ 2024-04-02 18:59 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-02 18:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6faca9ae2878c8f642a2e5748d2dbb2b91341bec Modified Files -------------- src/backend/postmaster/autovacuum.c | 21 +++++++++++++++++++- src/backend/storage/lmgr/lmgr.c | 38 +++++++++++++++++++++++++++++++++++++ src/include/storage/lmgr.h | 2 ++ 3 files changed, 60 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Avoid deadlock during orphan temp table removal. @ 2024-04-02 18:59 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-02 18:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4fb56a734d4c40c75ccfd8c4b2948266b8bf6e5d Modified Files -------------- src/backend/postmaster/autovacuum.c | 21 +++++++++++++++++++- src/backend/storage/lmgr/lmgr.c | 38 +++++++++++++++++++++++++++++++++++++ src/include/storage/lmgr.h | 2 ++ 3 files changed, 60 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Avoid deadlock during orphan temp table removal. @ 2024-04-02 18:59 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-02 18:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/cbfbb14bd7de9e90fb107cdcaa783264bf8fcdb9 Modified Files -------------- src/backend/postmaster/autovacuum.c | 21 +++++++++++++++++++- src/backend/storage/lmgr/lmgr.c | 38 +++++++++++++++++++++++++++++++++++++ src/include/storage/lmgr.h | 2 ++ 3 files changed, 60 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Avoid deadlock during orphan temp table removal. @ 2024-04-02 18:59 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-02 18:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ca392df8dd183f93575dd21f1b76390656ca9550 Modified Files -------------- src/backend/postmaster/autovacuum.c | 21 +++++++++++++++++++- src/backend/storage/lmgr/lmgr.c | 38 +++++++++++++++++++++++++++++++++++++ src/include/storage/lmgr.h | 2 ++ 3 files changed, 60 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Avoid deadlock during orphan temp table removal. @ 2024-04-02 18:59 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-02 18:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f5d9212e53913d091e63f081e136f08b5c1595ff Modified Files -------------- src/backend/postmaster/autovacuum.c | 21 +++++++++++++++++++- src/backend/storage/lmgr/lmgr.c | 38 +++++++++++++++++++++++++++++++++++++ src/include/storage/lmgr.h | 2 ++ 3 files changed, 60 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Avoid deadlock during orphan temp table removal. @ 2024-04-02 18:59 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-02 18:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4afc2c219d70ee7d12116aecda03d91c21ad6141 Modified Files -------------- src/backend/postmaster/autovacuum.c | 21 +++++++++++++++++++- src/backend/storage/lmgr/lmgr.c | 38 +++++++++++++++++++++++++++++++++++++ src/include/storage/lmgr.h | 2 ++ 3 files changed, 60 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-04-02 18:59 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-04-02 18:59 pgsql: Avoid deadlock during orphan temp table removal. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-02 18:59 pgsql: Avoid deadlock during orphan temp table removal. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-02 18:59 pgsql: Avoid deadlock during orphan temp table removal. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-02 18:59 pgsql: Avoid deadlock during orphan temp table removal. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-02 18:59 pgsql: Avoid deadlock during orphan temp table removal. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-02 18:59 pgsql: Avoid deadlock during orphan temp table removal. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox