Re: Non-text mode for pg_dumpall

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Non-text mode for pg_dumpall
Date: 2024-06-10 14:51:42
Message-ID: 8dcc13eb-d5a4-4af4-a00e-4470872aa853@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-06-10 Mo 10:14, Nathan Bossart wrote:
> On Mon, Jun 10, 2024 at 08:58:49AM -0400, Andrew Dunstan wrote:
>> Tom and Nathan opined recently that providing for non-text mode for
>> pg_dumpall would be a Good Thing (TM). Not having it has been a
>> long-standing complaint, so I've decided to give it a go.
> Thank you!
>
>> I think we would need to restrict it to directory mode, at least to begin
>> with. I would have a toc.dat with a different magic block (say "PGGLO"
>> instead of "PGDMP") containing the global entries (roles, tablespaces,
>> databases). Then for each database there would be a subdirectory (named for
>> its toc entry) with a standard directory mode dump for that database. These
>> could be generated in parallel (possibly by pg_dumpall calling pg_dump for
>> each database). pg_restore on detecting a global type toc.data would restore
>> the globals and then each of the databases (again possibly in parallel).
> I'm curious why we couldn't also support the "custom" format.

We could, but the housekeeping would be a bit harder. We'd need to keep
pointers to the offsets of the per-database TOCs (I don't want to have a
single per-cluster TOC). And we can't produce it in parallel, so I'd
rather start with something we can produce in parallel.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2024-06-10 14:52:06 Re: Non-text mode for pg_dumpall
Previous Message Dean Rasheed 2024-06-10 14:21:35 Re: Proposal to include --exclude-extension Flag in pg_dump