Re: Temporary tables prevent autovacuum, leading to XID wraparound
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-08-08T08:41:27Z
Lists: pgsql-hackers
Hi, On 2018-07-30 16:59:16 +0900, Michael Paquier wrote: > + /* > + * Mark MyProc as owning this namespace which other processes can use to > + * decide if a temporary namespace is in use or not. Even if this is an > + * atomic operation, this can be safely done lock-less as no temporary > + * relations associated to it can be seen yet if scanning pg_class. > + */ > + MyProc->tempNamespaceId = namespaceId; I can't parse this. "Even if this is an atomic operation, this can be safely done lock-less" - that seems like a contradictory sentence. Is there a "not" missing? Also, this seems like insufficient reasoning. What guarantees the visibility of the flag? You're going to have to talk about externally implied memory ordering here. Or add explicit barriers - the latter is probably preferrable. Greetings, Andres Freund
Commits
-
Clarify comment about assignment and reset of temp namespace ID in MyProc
- 9fc9933695af 11.0 landed
- 1339fcc89617 12.0 landed
-
Make autovacuum more aggressive to remove orphaned temp tables
- 943576bddcb5 11.0 landed
- 246a6c8f7b23 12.0 landed
-
Don't count background workers against a user's connection limit.
- 13752743bf70 9.6.2 cited