Horton

Re: removal of dangling temp tables

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-12-14T18:40:08Z
Lists: pgsql-hackers 
Hi,

On 2018-12-14 13:35:50 -0500, Tom Lane wrote:
> Hm.  It *could*, if we wanted it to run some transactions after
> finishing recovery.

How, we don't have infrastructure for changing databases yet?


> But I guess I wonder why bother; if the disk
> space is gone then there's not that much reason to be in a hurry
> to get rid of the catalog entries.  The particular problem Alvaro
> is complaining of might be better handled by ignoring temp tables
> while computing max freeze age etc.  I have some recollection that
> we'd intentionally included them, but I wonder why really; it's
> not like autovacuum is going to be able to do anything about an
> ancient temp table.

We can't truncate the clog, adapt the xid horizon, etc if there's any
temp tables. Otherwise you'd get failures when reading from one, no?

Greetings,

Andres Freund

Commits

  1. Have DISCARD ALL/TEMP remove leftover temp tables

  2. Make autovacuum more selective about temp tables to keep

  3. Make autovacuum more aggressive to remove orphaned temp tables

  4. autovacuum: Drop orphan temp tables more quickly but with more caution.