Re: Temporary tables prevent autovacuum, leading to XID wraparound
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
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-08T19:11:17Z
Lists: pgsql-hackers
Hi Andres, (Not my intention to miss your message, I have just noticed it.) On Wed, Aug 08, 2018 at 01:41:27AM -0700, Andres Freund wrote: > 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? Yes, a "not" has gone missing here. I reworked the comment block as mentioned upthread. > 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. Well, we use BackendIdGetProc() in this case, where we could finish with information out-of-date pretty quickly, and there is no special reasoning for backendId and databaseId for autovacuum but... Perhaps you could explain more what you have in mind? And it is not like this relies on the number of elements in PGPROC. -- Michael
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