On Fri, Jan 10, 2020 at 09:50:58AM -0500, Tom Lane wrote: > This doesn't seem like a very good idea to me. Is there any > evidence that it's fixing an actual problem? What if the table > you're skipping is holding back datfrozenxid?
That's the point I wanted to make sure: we don't because autovacuum has never actually been able to do that and because the cluster is put in this state by a superuser after issuing DROP SCHEMA on its temporary schema, which allows many fancy things based on the inconsistent state the session is on. Please see see for example REL_10_STABLE where GetTempNamespaceBackendId() would return InvalidBackendId when the namespace does not exist, so the drop is skipped. 246a6c8 (designed to track if a backend slot is using a temp namespace or not, allowing cleanup of orphaned tables if the namespace is around, still not used yet by the session it is assigned to) has changed the logic, accidentally actually, to also allow an orphaned temp table to be dropped even if its namespace does not exist anymore. If we say that it's fine for autovacuum to allow the drop of such inconsistent pg_class entries, then we would need to either remove or relax the assertion in relcache.c:1123 (RelationBuildDesc, should only autovacuum be allowed to do so?) to begin to allow autovacuum to remove temp relations. However, this does not sound like a correct thing to do IMO. So, note that if autovacuum is allowed to do so, you basically defeat partially the purpose of the assertion added by debcec7d in relcache.c. Another thing noticeable is that If autovacuum does the pg_class entry drops, the on-disk files for the temp relations would remain until the cluster is restarted by the way. -- Michael
signature.asc
Description: PGP signature