Re: Temporary tables prevent autovacuum, leading to XID wraparound

Michael Paquier <michael.paquier@gmail.com>

From: Michael Paquier <michael.paquier@gmail.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-01-25T08:17:12Z
Lists: pgsql-hackers
On Thu, Jan 25, 2018 at 08:10:00AM +0000, Tsunakawa, Takayuki wrote:
>>> * In this incident, autovacuum worker misjudged that
>>> pg_temp_3.fetchchunks can't be deleted, although the creator
>>> (pg_rewind) is no longer active.  How can we delete orphan temporary
>>> tables safely?
>> 
>> As long as Postgres sees that its temporary schema is in use, it would think
>> that the table is not orphaned. Another thing possible would be to have
>> the session now holding this schema space to reuse fetchchunks so as things
>> are reset.
> 
> I understood you suggested a new session which recycle the temp schema
> should erase the zombie metadata of old temp tables or recreate the
> temp schema.  That sounds easy. 

If the new session makes use of the same temporary schema where the
orphan table is, cleanup is possible. Now you have a problem if this is
not available as this depends on the backend ID uniquely assigned. It
would be better to just drop the table manually at the end.
--
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.