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

From Marko Grujic
Subject Re: Temp schema drop leaves an inconsistent state behind
Date
Msg-id CAOvwyF2_8yOOuuZm9K9aRfB8LUbZC+_r97Np9ohwJArEFdYWag@mail.gmail.com
Whole thread
In response to Re: Temp schema drop leaves an inconsistent state behind  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Temp schema drop leaves an inconsistent state behind
List pgsql-hackers
Hi all, thanks for testing and commenting.

On Fri, Sep 25, 2026 at 3:48 AM Michael Paquier <michael@paquier.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



pgsql-hackers by date:

Previous
From: "Wei Sun"
Date:
Subject: Re: Severe performance degradation with concurrent updates due to excessive EvalPlanQual (EPQ) re‑evaluation
Next
From: Bertrand Drouvot
Date:
Subject: Re: BUG: pg_class.relchecks overflow, making table undroppable