Skip site navigation (1) Skip section navigation (2)

Re: Big 7.1 open items

From: "Philip J(dot) Warner" <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, "Thomas Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
Subject: Re: Big 7.1 open items
Date: 2000-06-22 07:50:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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 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://          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from   |/

In response to


pgsql-hackers by date

Next:From: Giles LeanDate: 2000-06-22 08:47:43
Subject: Re: An idea on faster CHAR field indexing
Previous:From: Tom LaneDate: 2000-06-22 07:17:45
Subject: Re: Big 7.1 open items

pgsql-patches by date

Next:From: Denis PerchineDate: 2000-06-22 08:05:34
Subject: Re: [GENERAL] libpq error codes
Previous:From: Tom LaneDate: 2000-06-22 07:30:19
Subject: Re: libpq error codes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group