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