Re: Temporary tables prevent autovacuum, leading to XID wraparound

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Temporary tables prevent autovacuum, leading to XID wraparound
Date: 2018-08-08 08:41:27
Message-ID: 20180808084127.azivmkge4lxhs2ry@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-08-08 10:24:07 Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian
Previous Message Michael Paquier 2018-08-08 08:33:06 Re: Temporary tables prevent autovacuum, leading to XID wraparound