Re: trouble migrating large objects from 7.1.3 to 7.3.2 - Mailing list pgsql-admin

From jml@attbi.com
Subject Re: trouble migrating large objects from 7.1.3 to 7.3.2
Date
Msg-id 20030422170701.E90A8474E42@postgresql.org
Whole thread Raw
In response to trouble migrating large objects from 7.1.3 to 7.3.2  ("John M. Layman" <jml@frijid.net>)
List pgsql-admin
Tom/Philip - I've tried with the -o option on the dump side only & I get the
original problem - the OID's in the new database just increase by 2.  The data
is there, though, because the disc space decreases.

I was originally running pg_dump & pg_restore without the -o options, but when
I saw it wasn't working, I tried using the -o options in various combinations
(pg_ dump only, pg_restore only & both).

From what the docs say, I shouldn't need these options, but I tried them as a
last resort.



"John M. Layman" <jml@frijid.net> writes:
> pg_dump -p 6543 -b -Ft -v -o dbase | pg_restore -p 5432 -Ft -v -o -d dbase

> The above command causes pg_restore to fail with the following error:

> pg_restore: [tar archiver] could not find header for file 37.dat in tar
archive

Philip Warner points out that "-o" for pg_restore means "restore in OID
order", which requires seeking in the input file, which won't work on
piped input.  Try it without the -o on the restore side.  (Offhand I'd
bet that you don't really want -o on the dump side, either, but that's
a different issue.)

The error messages do leave something to be desired :-(

            regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly


pgsql-admin by date:

Previous
From: John Smith
Date:
Subject: upgrade problems
Next
From: "Ricardo Sardano Guanciale"
Date:
Subject: no password required