| 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 |