Re: Temp schema drop leaves an inconsistent state behind

Hi all, thanks for testing and commenting.

On Fri, Sep 25, 2026 at 3:48 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> All these actions are doable only under a superuser, and there is an
> argument over the existing behavior being useful, for example to clean
> up orphaned objects post-crash-recovery.
>
> Superusers can do worse than that. For example issue a TRUNCATE on a
> few catalogs like pg_database, with set allow_system_table_mods =
> true. Now, that's much more interesting.

In that case the superuser is opting-in to something explicitly dangerous.

> My point being: we did not care back then for the reasons given back
> then related to superusers. Why should we care now? This discussion
> was feeling as a waste of precious resources back then; it still feels
> the same today.

I wasn't aware of those discussions, but unlike above, DROP SCHEMA
pg_temp_N looks innocent enough, yet it can break pg_dump (not to
mention the segfault) which seemed severe enough to me to warrant a fix.

Still if this is the consensus I don't mind leaving that as is.

That said I do think that the first part of the patch (0001, which fixes the
two identify-object functions) has merit on its own. If nothing else, then
at least to gracefully handle the existing behavior for temp schema drops.
I can post it separately with a regression test if there's interest.

Thanks,
Marko