Alvaro Herrera <alvhe...@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