From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Michael Paquier <michael@paquier.xyz>,
 Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: removal of dangling temp tables
In-reply-to: <20181215132116.5v25mjgyy7y77pzw@alvherre.pgsql>
References: <20181215132116.5v25mjgyy7y77pzw@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Sat, 15 Dec 2018 10:21:16 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23464.1544885491.1@sss.pgh.pa.us>
Date: Sat, 15 Dec 2018 09:51:31 -0500
Message-ID: <23465.1544885491@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2018-Dec-15, Michael Paquier wrote:
>> Isn't that what tempNamespaceId can be used for in PGPROC now?  The flag
>> would be set only when a backend creates a new temporary schema so as it
>> can be tracked as the owner of the schema.

> Oh, we already have it!  Sorry, I overlooked it.  With that, it seems
> the patch is fairly simple ... I wonder about the locking implications
> in autovacuum, though -- the value is set in backends without acquiring
> a lock.

I was wondering about that too.  But I think it's probably OK.  If
autovacuum observes that (a) a table is old enough to pose a wraparound
hazard and (b) its putatively owning backend hasn't yet set
tempNamespaceId, then I think it's safe to conclude that that table is
removable, despite the theoretical race condition.

Autovacuum would need to acquire a deletion lock and then check that the
table is still there, to avoid race conditions if the backend starts to
clean out the schema immediately after it looks.  But I think those race
conditions exist anyway (consider a fresh backend that starts cleaning out
its temp schema immediately), so if we have a problem with concurrent
deletion attempts then that problem exists already.

> I wonder how this thing works in parallel query workers.

Surely workers are not allowed to create or delete temp tables.

			regards, tom lane