From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | Basha <Basha(at)maxcontact(dot)com> |
Cc: | 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 00:29:52 |
Message-ID: | 6860E1BC-DA5A-4576-9FB6-35ED31E6F017@thebuild.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On Sep 6, 2024, at 16:44, Basha <Basha(at)maxcontact(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Basha | 2024-09-07 00:32:45 | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
Previous Message | Tom Lane | 2024-09-07 00:24:59 | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |