Re: Temp schema drop leaves an inconsistent state behind - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Temp schema drop leaves an inconsistent state behind
Date
Msg-id arXS60W_UEBcqZlr@paquier.xyz
Whole thread
In response to Re: Temp schema drop leaves an inconsistent state behind  (Manu <manuelreyesbravo@gmail.com>)
Responses Re: Temp schema drop leaves an inconsistent state behind
Re: Temp schema drop leaves an inconsistent state behind
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Manu
Date:
Subject: Re: Speed up lpad() and rpad() for one-byte padding strings
Next
From: Khoa Nguyen
Date:
Subject: Re: HASH INDEX builds seems confused