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

From Michael Paquier
Subject Re: Temporary tables prevent autovacuum, leading to XID wraparound
Date
Msg-id 20180713042957.GA23895@paquier.xyz
Whole thread Raw
In response to RE: Temporary tables prevent autovacuum, leading to XID wraparound  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: Temporary tables prevent autovacuum, leading to XID wraparound  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On Tue, Mar 13, 2018 at 08:08:48AM +0000, Tsunakawa, Takayuki wrote:
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> On the whole, my vote is to fix and apply step 2, and leave it at that.

Yeah, I have been thinking about the idea 1 mentioned above, or in short
clean up the temporary namespace at connection start instead of
first-use of it, and while that would make the cleanup more aggressive,
it could be possible as well that only having autovacuum do the work
could be enough, so I am +-0 on this idea.

> Done.  It seems to work well.

I have looked at the patch proposed.

+   /* Does the backend own the temp schema? */
+   if (proc->tempNamespaceId != namespaceID)
+       return false;
I have a very hard time believing that this is safe lock-less, and a
spin lock would be enough it seems.

+   /* Is the backend connected to this database? */
+   if (proc->databaseId != MyDatabaseId)
+       return false;
Wouldn't it be more interesting to do this cleanup as well if the
backend is *not* connected to the database autovacuum'ed?  This would
make the cleanup more aggresive, which is better.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Cache invalidation after authentication (on-the-fly role creation)
Next
From: Amit Langote
Date:
Subject: Re: How to make partitioning scale better for larger numbers ofpartitions