Re: Temp schema drop leaves an inconsistent state behind

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Marko Grujic <marko(dot)grujic(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Manu <manuelreyesbravo(at)gmail(dot)com>, Marko Grujic <markoog(at)gmail(dot)com>
Subject: Re: Temp schema drop leaves an inconsistent state behind
Date: 2026-09-25 12:09:51
Message-ID: 34b316b3-a99b-4f05-89bc-397df270817f@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25/09/2026 10:38, Marko Grujic wrote:
> 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.

I think Michael is right, superusers can do all sort of destructive
things -- I keep falling into this trap as well. I guess the trick here
for superusers would be "don't mess with the catalog unless you know
what you're doing" :)

Best, Jim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2026-09-25 12:12:33 Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Previous Message Matheus Alcantara 2026-09-25 11:45:06 Re: RI fastpath misses checking EXECUTE on functions