Peter Eisentraut [EMAIL PROTECTED] writes:
Btw., it would really seem like a neat feature if a given pg_dump suite
would also handle the respective previous version. Otherwise we're in a
situation like now where we've got a shiny new pg_dump but people that
want to upgrade are still stuck
At 01:09 11/04/01 +0200, Peter Eisentraut wrote:
Btw., it would really seem like a neat feature if a given pg_dump suite
would also handle the respective previous version.
This has been in the back of my mind for some time, and is why I initially
backported my pg_dump changes to 7.0.
At 06:27 11/04/01 -0400, D'Arcy J.M. Cain wrote:
Finding and fixing one 7 row table
in a multi-gigabyte files really sucks. :-)
At least in 7.1 you can dump the who DB to a file/tape, then extract one
table from the dump file easily...
At 17:18 11/04/01 +0200, Peter Eisentraut wrote:
What I meant was that whenever the backend changes in a way that mandates
pg_dump changes we would leave the old way in place and only add a new
case to handle the new backend.
That's what I had in mind as well; I gave up on the backport because
On Tue, 10 Apr 2001, The Hermit Hacker wrote:
all I did was use pg_dumpall from v7.0.3 to dump to a text file, and
"psql template1 dumpfile" to load it back in again ...
obviously this doesn't work like it has in the past?
Marc --
Was there an error message during restore?
I've been
No errors, nothing ... here is the backend:
%bin/postmaster -D /usr/local/pgsql/data
DEBUG: database system was shut down at 2001-04-10 15:04:08 ADT
DEBUG: CheckPoint record at (0, 1522068)
DEBUG: Redo record at (0, 1522068); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId:
