Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
От | Basha |
---|---|
Тема | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
Дата | |
Msg-id | GV1P194MB2356082D55A66B1F659F1AA5D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications (Christophe Pettus <xof@thebuild.com>) |
Список | pgsql-bugs |
Thank you, will there be any possibility of introducing a more granular control over pg_dump in such cases? Which would really helpful.
Thank you,
Basha
From: Christophe Pettus <xof@thebuild.com>
Sent: Saturday, September 7, 2024 1:29:52 AM
To: Basha <Basha@maxcontact.com>
Cc: 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
Sent: Saturday, September 7, 2024 1:29:52 AM
To: Basha <Basha@maxcontact.com>
Cc: 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 6, 2024, at 16:44, Basha <Basha@maxcontact.com> wrote:
> If shadowing system catalogs via views is not a recommended path, we would be grateful for guidance on alternative approaches to achieve the same result—restricting visibility of databases in a multi-tenant environment while maintaining essential operations like backups. Specifically, is there a supported way to enforce database isolation at the system catalog level, or is there a possibility of introducing a more granular control over pg_dump in such cases?
The closest analogy that I've seen in the field is what Heroku does (did?) for database-based multitenancy, which is to assign very random names to the databases, without revealing any client names or other human-readable data. That the databases existed was still visible in pg_database, but it leaked no substantial information to users connected to other databases.
В списке pgsql-bugs по дате отправления: