Re: Modified pg_dump & new pg_restore need testing...

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Modified pg_dump & new pg_restore need testing...
Date: 2000-06-30 16:53:36
Message-ID: Pine.BSF.4.21.0006301349080.773-100000@thelab.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Sounds like something that is a suitable replacement for what we have now
... I particularly like the 'compressed output' *but* is there some way,
for the paranoid, of doing an uncompressed format
(--dont-compress?)? Then again, how does this handle someone wanting to
dump the database for reloading into a non-PgSQL database?

On Fri, 30 Jun 2000, Philip Warner wrote:

>
> If anyone is interested in being sent the current sources for the new
> pg_dump & pg_restore, please let me know.
>
> The utilities now seem to work, but need testing.
>
> The basic idea is to use pg_dump to dump an *entire* database, and then use
> pg_restore to choose what is restored.
>
> The salient features are as follows:
>
> - pg_dump still used to dump database; all output is via new interface
> (virtually all of the pg_dump code is changed, but not the logic). The
> changes are relatively minor, all the same.
>
> - the '-c' option is not used in pg-dump: it now dumps the commands to
> delete the schema, and it is up to the user of pg_restore to decide if they
> are output.
>
> - the default output file format is a custom format with compressed
> sections (the data dumps). It is NOT a text file.
>
> - pg_restore reads the backup file and, depending on the options chosen,
> produces a script (to stdout) that can be sent to psql.
>
> - by default pg_restore outputs the schema/data in the order it was sent
> from pg_dump, but the --oid flag will send the output in order of
> increasing OID, and the --rearrange flag will put all 'non-parental' (??)
> items at the end, after the data. (eg. indexes, acls, triggers etc).
> Needless to say that the best results com from using both of these options.
>
> - If the -c (clear) option is chosen in pg_restore, it also dumps the
> 'drop' commands in reverse order at the start of the script. This *should*
> make it more reliable than dumping them when the item is defined. It also
> means that triggers can be dropped.
>
> - The --toc option shows a summary of the restore operation that would be
> performed if the --toc were not there.
>
> Please send me an email if you are interested and have the time to test them.
>
> Thanks,
>
> Philip Warner.
>
>
> ----------------------------------------------------------------
> Philip Warner | __---_____
> Albatross Consulting Pty. Ltd. |----/ - \
> (A.C.N. 008 659 498) | /(@) ______---_
> Tel: (+61) 0500 83 82 81 | _________ \
> Fax: (+61) 0500 83 82 82 | ___________ |
> Http://www.rhyme.com.au | / \|
> | --________--
> PGP key available upon request, | /
> and from pgp5.ai.mit.edu:11371 |/
>

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-06-30 23:52:57 Re: Modified pg_dump & new pg_restore need testing...
Previous Message Peter Eisentraut 2000-06-30 16:22:50 Re: finding lib/include dirs