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

  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.