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