Re: Temporary tables prevent autovacuum, leading to XID wraparound
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org,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-09T03:02:32Z
Lists: pgsql-hackers
On August 9, 2018 12:41:17 AM GMT+05:30, Michael Paquier <michael@paquier.xyz> wrote: >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. My point is that the documentation isn't sufficient. Not that there's an active problem. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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