RE: Temporary tables prevent autovacuum, leading to XID wraparound
Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Michael Paquier' <michael@paquier.xyz>
Cc: 'Tom Lane' <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-07-18T07:34:10Z
Lists: pgsql-hackers
From: Michael Paquier [mailto:michael@paquier.xyz] > + /* 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. The lwlock in BackendIdGetProc() flushes the CPU cache so that proc->tempNamespaceId reflects the latest value. Or, do you mean another spinlock elsewhere? > + /* 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. IIUC, the above code does what you suggest. proc->databaseId is the database the client is connected to, and MyDatabaseId is the database being autovacuumed (by this autovacuum worker.) Regards Takayuki Tsunakawa
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