Re: removal of dangling temp tables

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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