Re: Temporary tables prevent autovacuum, leading to XID wraparound

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: 'Tom Lane' <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-07-13T04:29:57Z
Lists: 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

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.