Re: AW: Proposal: More flexible backup/restore via pg_dump

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump
Date: 2000-06-27 15:08:03
Message-ID: 3.0.5.32.20000628010803.0226f100@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 10:48 27/06/00 -0400, Tom Lane wrote:
>
>Right, the thing we *really* want is to preserve the fact that pg_dump
>can write its output to a pipeline ... and that a restore can read from
>one. If you can improve performance when you find you do have a
>seekable source/destination file, fine, but the utilities must NOT
>require it.

OK, the limitation will have to be that reordering of *data* loads (as
opposed to metadata) will not be possible in piped data. This is only a
problem if RI constraints are loaded.

I *could* dump the compressed data to /tmp, but I would guess that in most
cases when the archive file is being piped it's because the file won't fit
on a local disk.

Does this sound reasonable?

>> I guess we would want two formats, one for pipe, and one for a standard
>> directory.
>
>At the risk of becoming tiresome, "tar" format is eminently pipeable...
>

No, it's good...I'll never feel guilty about asking for optimizer hints again.

More seriously, though, if I pipe a tar file, I still can't reorder the
*data* files without saving them to disk, which is what I want to avoid.

----------------------------------------------------------------
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 |/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-06-27 15:15:01 Re: AW: SQL99 functions
Previous Message Thomas Lockhart 2000-06-27 15:07:31 Re: AW: SQL99 functions