From: | Basha <Basha(at)maxcontact(dot)com> |
---|---|
To: | Christophe Pettus <xof(at)thebuild(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | RE: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
Date: | 2024-09-07 17:51:08 |
Message-ID: | GV1P194MB2356E8A0BCE25A4EB08AF8B7D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 are in a stranded position on this issue.
Thank you very much for your support and guidance.
-----Original Message-----
From: Christophe Pettus <xof(at)thebuild(dot)com>
Sent: 07 September 2024 18:29
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Basha <Basha(at)maxcontact(dot)com>; Joe Conway <mail(at)joeconway(dot)com>; PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)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(at)sss(dot)pgh(dot)pa(dot)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 major versions out at a minimum, which is annoying for existing users who want multi-tenancy based on databases. But companies like 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: City View House, 5 Union Street, Ardwick, Manchester M12 4JD. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. Any views or options presented are solely those of the author and do not necessarily represent those of Trivoni Software Limited. Internet communications are not secure and therefore Trivoni Software Limited does not accept legal responsibility for the contents of this message. If you are not the intended recipient, you are hereby notified that you have received this e-mail in 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 from alterations of the contents of this message by a third party or as a result of any VIRUS being passed on. Any pricing details or other offers delivered via e-mail are not binding. If appropriate, an official purchase order quotation confirming pricing and bearing an authorisation signature will be provided via Docusign on request. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail without taking any copies or forwarding it elsewhere.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-09-07 18:21:33 | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
Previous Message | Christophe Pettus | 2024-09-07 17:29:14 | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |