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