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
-
Clarify comment about assignment and reset of temp namespace ID in MyProc
- 9fc9933695af 11.0 landed
- 1339fcc89617 12.0 landed
-
Make autovacuum more aggressive to remove orphaned temp tables
- 943576bddcb5 11.0 landed
- 246a6c8f7b23 12.0 landed
-
Don't count background workers against a user's connection limit.
- 13752743bf70 9.6.2 cited