Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

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