At 03:17 22/06/00 -0400, Tom Lane wrote:
>
>> This worries me a little; in the Dec/RDB world it is a very long time since
>> database backups were done by copying the files. There is a database
>> backup/restore utility which runs while the database is on-line and makes
>> sure a valid snapshot is taken. Backing up storage areas (table spapces)
>> can be done separately by the same utility, and again, it records enough
>> information to ensure integrity. Maybe the thing to do is write a pg_backup
>> utility, which in a first pass could, presumably, be synonymous with
pg_dump?
>
>pg_dump already does the consistent-snapshot trick (it just has to run
>inside a single transaction).
>
>> Am I missing something here? Is there a problem with backing up using
>> 'pg_dump | gzip'?
>
>None, as long as your ambition extends no further than restoring your
>data to where it was at your last pg_dump. I was thinking about the
>all-too-common-in-the-real-world scenario where you're hoping to recover
>some data more recent than your last backup from the fractured shards
>of your database...
>
pg_dump is a good basis for any pg_backup utility; perhaps as you indicated
elsewhere, more carefull formatting of the dump files would make
table-based restoration possible. In another response, I also suggested
allowing overrides of placement information in a restore operation- the
simplest approach would be an 'ignore-storage-parameters' flag. Does this
sound reasonable? If so, then discussion of file-id based on OID needs not
be too concerned about how db restoration is done.
----------------------------------------------------------------
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 |/