Re: Non-text mode for pg_dumpall - Mailing list pgsql-hackers

From Guillaume Lelarge
Subject Re: Non-text mode for pg_dumpall
Date
Msg-id CAECtzeXHvNNmVPwysJsCFoqfej4fx-bbzf+myjsM5Umj7kG_Pg@mail.gmail.com
Whole thread Raw
In response to Non-text mode for pg_dumpall  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Hi,

Le mer. 8 janv. 2025 à 17:41, Mahendra Singh Thalor <mahi6run@gmail.com> a écrit :
On Wed, 8 Jan 2025 at 20:07, Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
>
> Hi all,
>
> On Wed, 8 Jan 2025 at 00:34, Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
> >
> > On Mon, 6 Jan 2025 at 23:05, Nathan Bossart <nathandbossart@gmail.com> wrote:
> > >
> > > On Thu, Jan 02, 2025 at 02:05:13AM +0530, Mahendra Singh Thalor wrote:
> > > > Here, I am attaching an updated patch. I fixed some bugs of v01 patch and
> > > > did some code cleanup also.
> > >
> > > Thank you for picking this up!  I started to review it, but the
> > > documentation changes didn't build, and a few tests in check-world are
> > > failing.  Would you mind resolving those issues?  Also, if you haven't
> > > already, please add an entry to the next commitfest [0] to ensure that 1)
> > > this feature is tracked and 2) the automated tests will run.
> >
> > Thanks Nathan for the quick response.
> >
> > I fixed bugs of documentation changes and check-world in the latest patch. Now docs are building and check-world is passing.
> >
> > I added entry into commitfest for this patch.[0]
> >
> > >
> > > +       if (dbfile)
> > > +       {
> > > +               printfPQExpBuffer(&cmd, "\"%s\" %s %s", pg_dump_bin,
> > > +                                                 dbfile, create_opts);
> > > +               appendPQExpBufferStr(&cmd, " -F d ");
> > > +       }
> > >
> > > Have you given any thought to allowing a directory of custom format files,
> > > as discussed upthread [1]?  Perhaps that is better handled as a follow-up
> > > patch, but it'd be good to understand the plan, anyway.
> >
> > I will make these changes and will test. I will update my findings after doing some testing.
>
> In the latest patch, I added dump and restoring for directory/custom/tar/plain formats. Please consider this patch for review and testing.
>
> Design:
> When we give --format=d|c|t then we are dumping all global sql commands in global.dat in plain sql format and we are making a map.dat file with dbname and dboid. For each database, we are making separate subdirectory with dboid under databases directory and dumping as per archive format(d|c|t).
> While restoring, first we are restoring all global sql commands from global.dat and then we are restoring one by one all databases.  As we are supporting --exclude-database with pg_dumpall, the same we are supporting with pg_restore also to skip restoring on some specified database patterns.
> If we want to restore a single database, then we can specided particular subdirectory from the databases folder. To get file name, we refer dbname into map.file.
>
> TODO: Now I will work on test cases for these new added options to the pg_dumpall and pg_restore.
>
> Here, I am attaching the v04 patch for testing and review.

Sorry. My mistake.
v04 was the delta patch on the top of v03.

Here, I am attaching the v05 patch for testing and review.


Just FWIW, I did a quick test tonight. It applies cleanly, compiles OK. I did a dump:

$ pg_dumpall -Fd -f dir

and then a restore (after dropping the databases I had):

$ pg_restore -Cd postgres -v dir

It worked really well. That's great.

Quick thing to fix: you've got this error message:
pg_restore: error:  -d/--dbanme should be given when using archive dump of pg_dumpall

I guess it is --dbname, rather than --dbanme.

Of course, it needs much more testing, but this feature would be great to have. Thanks for working on this!


--
Guillaume.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: AIO v2.0
Next
From: Peter Eisentraut
Date:
Subject: Re: Coccinelle for PostgreSQL development [4/N]: correcting palloc() use