Re: Temporary tables prevent autovacuum, leading to XID wraparound - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Temporary tables prevent autovacuum, leading to XID wraparound
Date
Msg-id 20180809092954.jinn264bdvnf3di2@alap3.anarazel.de
Whole thread Raw
In response to Re: Temporary tables prevent autovacuum, leading to XID wraparound  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Temporary tables prevent autovacuum, leading to XID wraparound
List pgsql-hackers
On 2018-08-09 09:00:29 +0200, Michael Paquier wrote:
> On Thu, Aug 09, 2018 at 08:32:32AM +0530, Andres Freund wrote:
> > My point is that the documentation isn't sufficient. Not that there's an active problem.
> 
> OK.  Attached is the latest version if the patch I have that I was
> preparing for commit.
> 
> On top of isTempNamespaceInUse I have this note:
> + * Note: this can be used while scanning relations in pg_class to detect
> + * orphaned temporary tables or namespaces with a backend connected to a
> + * given database.
> 
> Would you be fine if I add an extra note like what's in
> BackendIdGetProc?  Say "The result may be out of date quickly, so the
> caller must be careful how to handle this information."

That's a caveat, not a documentation of the memory ordering /
concurrency. You somewhere need a comment to the effect of "We are
guaranteed to see a recent enough value of ->tempNamespace because
anybody creating a temporary table acquires a lock - serving as a memory
barrier - during the creation of said table, after assigning the
tempNamespace variable. At the same time, before considering dropping a
temporary table as orphaned, we acquire a lock and recheck tempNamespace
afterwards".  Note that I'm not explaining the concrete model you have
here, but the way you could explain a theoretical one.

- Andres


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Next
From: Devrim Gündüz
Date:
Subject: 9.6.10 build warning on Fedora 28