From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: removal of dangling temp tables
In-reply-to: 
 <CA+TgmoaU-rRTOsYy9o6nj6h58tg49dhUd0u3XFGJ_GvdOFLmZw@mail.gmail.com>
References: <20181214162843.37g6h3txto43akrb@alvherre.pgsql>
 <CA+TgmoYdgL7pRBAkucZoZriVExJvS+TqGZ7yZNF0roi7FiHwLA@mail.gmail.com>
 <8545.1544810243@sss.pgh.pa.us>
 <CA+TgmoaU-rRTOsYy9o6nj6h58tg49dhUd0u3XFGJ_GvdOFLmZw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 14 Dec 2018 13:16:30 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9968.1544812550.1@sss.pgh.pa.us>
Date: Fri, 14 Dec 2018 13:35:50 -0500
Message-ID: <9969.1544812550@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 14, 2018 at 12:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I seem to recall discussions about having crash recovery go around
>> and clean out temp tables.  That seems like a better plan than
>> penalizing every session start with this.

> Well, crash recovery already removes the files, but it can't really
> remove the catalog entries, can it?

Hm.  It *could*, if we wanted it to run some transactions after
finishing recovery.  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.

Alternatively, maybe we could have backends flag whether they've
taken ownership of their temp schemas or not, and let autovacuum
flush old temp tables if not?

			regards, tom lane