From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Michael Paquier' <michael(dot)paquier(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Temporary tables prevent autovacuum, leading to XID wraparound |
Date: | 2018-01-25 08:10:00 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F8A4F70@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> From: Michael Paquier [mailto:michael(dot)paquier(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-01-25 08:17:12 | Re: Temporary tables prevent autovacuum, leading to XID wraparound |
Previous Message | Michael Paquier | 2018-01-25 07:55:00 | Re: Temporary tables prevent autovacuum, leading to XID wraparound |