Re: Temp schema drop leaves an inconsistent state behind

On Thu, Sep 24, 2026 at 11:28:54AM -0300, Manu wrote:
>> On top of that, a just dropped schema can still be used to create
>> temporary objects, which creates a pg_class orphan:
>> IIUC the problem is that activeCreationNamespace is used when the
>> relpersistence is not RELPERSISTENCE_TEMP. So with pg_temp first in
>> search_path, activeCreationNamespace is the dropped schema.

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.

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.

> That's right, and 0002 does not cover it, nor does my diff on top of
> it. I ran each kind of CREATE as the first statement after the drop,
> with pg_temp first in search_path and no TEMP keyword, one fresh
> cluster per statement, on master and with 0001+0002 (the rollback diff
> gives the same results):

This comment does not apply only to this thread, more to the recent
activities of this email address: note that most of your reviews,
being clearly AI-generated, are rather noisy (not all, but a large
majority), and sometimes miss the point while providing a sloppy
amount of confusing contents.
--
Michael