On Sat, Dec 15, 2018 at 09:51:31AM -0500, Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.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
signature.asc
Description: PGP signature
