Re: removal of dangling temp tables

On Sat, Dec 15, 2018 at 09:51:31AM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> 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.

This relies on the fact that the flag gets set by a backend within a
transaction context, and autovacuum would not see yet temp relations
associated to it at the moment of the scan of pg_class if the backend
has not committed yet its namespace creation via the creation of the
first temp table it uses.

> 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.

Yes, InitTempTableNamespace prevents their creation and InitLocalBuffers
prevents their access as buffers of temp tables are local to a backend
and cannot be shared across multiple workers. Amit Kapila has been
working on this problem lately for example.
--
Michael