Re: trouble migrating large objects from 7.1.3 to 7.3.2
От | jml@attbi.com |
---|---|
Тема | Re: trouble migrating large objects from 7.1.3 to 7.3.2 |
Дата | |
Msg-id | 20030422170701.E90A8474E42@postgresql.org обсуждение исходный текст |
Ответ на | trouble migrating large objects from 7.1.3 to 7.3.2 ("John M. Layman" <jml@frijid.net>) |
Список | 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 по дате отправления: