RE: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications - Mailing list pgsql-bugs

From Basha
Subject RE: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Date
Msg-id GV1P194MB2356E8A0BCE25A4EB08AF8B7D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications  (Christophe Pettus <xof@thebuild.com>)
List pgsql-bugs
The fix in PG16.4, entirely prevents changes to pg_database, Is there any possibility of a more targeted approach.
Specifically,I'd like to know if there's an option to modify this fix so that it applies only to specific areas or
actions,rather than enforcing a complete restriction. 

The suggestion to add RLS to the system catalog table would be great solution in order to find a solution. Currently we
arein a stranded position on this issue. 

Thank you very much for your support and guidance.



-----Original Message-----
From: Christophe Pettus <xof@thebuild.com>
Sent: 07 September 2024 18:29
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Basha <Basha@maxcontact.com>; Joe Conway <mail@joeconway.com>; PostgreSQL Bug List
<pgsql-bugs@lists.postgresql.org>
Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table
Modifications



> On Sep 7, 2024, at 10:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Still, making such a change would amount to actively supporting RLS on
> catalogs, rather than just a laissez-faire "you can use it if it
> works" approach.

I don't want to get into analysis paralysis on this, but I think it makes more sense to have proactive multi-tenancy
features,rather than trying to press the existing infrastructure into service for it.  This means it's a couple of
majorversions out at a minimum, which is annoying for existing users who want multi-tenancy based on databases.  But
companieslike Heroku have been making it (somewhat imperfectly) work for over a decade now, so it's not impossible. 
MaxContact is a trading style of Trivoni Software Limited. Registration Number: England 09816677. Registered Office:
CityView House, 5 Union Street, Ardwick, Manchester M12 4JD. This e-mail and any files transmitted with it are
confidentialand intended solely for the use of the individual or entity to whom it is addressed. Any views or options
presentedare solely those of the author and do not necessarily represent those of Trivoni Software Limited. Internet
communicationsare not secure and therefore Trivoni Software Limited does not accept legal responsibility for the
contentsof this message. If you are not the intended recipient, you are hereby notified that you have received this
e-mailin error and that any use, disclosure, dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.Trivoni Software Limited will not be liable for direct, special, indirect or consequential damage arising
fromalterations of the contents of this message by a third party or as a result of any VIRUS being passed on. Any
pricingdetails or other offers delivered via e-mail are not binding. If appropriate, an official purchase order
quotationconfirming pricing and bearing an authorisation signature will be provided via Docusign on request. If you
havereceived this e-mail in error, please notify the sender immediately and delete the e-mail without taking any copies
orforwarding it elsewhere. 



pgsql-bugs by date:

Previous
From: Christophe Pettus
Date:
Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Next
From: Tom Lane
Date:
Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications