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@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-01-25T08:10:00Z
Lists: pgsql-hackers
> From: Michael Paquier [mailto:michael.paquier@gmail.com]
> As a superuser, DROP TABLE should work on the temporary schema of another
> session. Have you tried that to solve the situation?

Yes, we asked the customer to do that today.  I think the customer will do in the near future.

> > * 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.

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.