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

  1. Clarify comment about assignment and reset of temp namespace ID in MyProc

  2. Make autovacuum more aggressive to remove orphaned temp tables

  3. Don't count background workers against a user's connection limit.