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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump
Date: 2000-06-27 15:23:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> 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.

True.  This is not an issue on the dump side, of course, since you can
choose what order you're going to write the tables in.  On the restore
side, you have no alternative but to restore the tables in the order
they appear on tape.  Of course the DBA can run the restore utility
more than once and extract a subset of tables each time, but I don't
see how the restore utility can be expected to do that for him.
(Except if it finds it does have the ability to seek in its input file,
but I dunno if it's a good idea to use that case for anything except
under-the-hood performance improvement, ie quickly skipping over the
data you don't need.  Features that don't work all the time are not
good in my book.)

Basically I think we want to assume that pg_dump will write the tables
in an order that's OK for restoring.  If we can arrange for RI checks
not to be installed until after all the data is loaded, this shouldn't
be a big problem, seems like.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Denis PerchineDate: 2000-06-27 16:12:59
Subject: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Previous:From: Tom LaneDate: 2000-06-27 15:15:01
Subject: Re: AW: SQL99 functions

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