Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications

Поиск
Список
Период
Сортировка
От Christophe Pettus
Тема Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Дата
Msg-id 6860E1BC-DA5A-4576-9FB6-35ED31E6F017@thebuild.com
обсуждение исходный текст
Ответ на BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Список pgsql-bugs

> 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
approachesto achieve the same result—restricting visibility of databases in a multi-tenant environment while
maintainingessential operations like backups. Specifically, is there a supported way to enforce database isolation at
thesystem 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
assignvery random names to the databases, without revealing any client names or other human-readable data.  That the
databasesexisted was still visible in pg_database, but it leaked no substantial information to users connected to other
databases.




В списке pgsql-bugs по дате отправления: