Re: error restoring large objects during pg_restore
От | Ron Snyder |
---|---|
Тема | Re: error restoring large objects during pg_restore |
Дата | |
Msg-id | F888C30C3021D411B9DA00B0D0209BE803BBA62B@cvo-exchange.cvo.roguewave.com обсуждение исходный текст |
Ответ на | error restoring large objects during pg_restore (Ron Snyder <snyder@roguewave.com>) |
Список | pgsql-general |
This is with postgresql 7.2.1 (we're in the process of moving to 7.3.3). I believe that the chance of file corruption should be very low-- Windows boxes have no opportunity to touch this file. The server is a RH Linux box with logical volumes (both as storage for the dump files and the storage for the database). Thanks for looking! I'm currently "strace"ing the pg_restore to see if that lends any clues. -ron > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Tuesday, June 10, 2003 4:04 PM > To: Ron Snyder > Cc: 'pgsql-general@postgresql.org'; Philip Warner > Subject: Re: [GENERAL] error restoring large objects during > pg_restore > > > Ron Snyder <snyder@roguewave.com> writes: > > I'm trying to pg_restore a database using a process that > I've used a bunch > > (10-15) times in the past, and this is the first time it's > ever failed on > > me. It's failing with the following error: > > > pg_restore: creating table for large object cross-references > > pg_restore: [custom archiver] could not read data block - > expected 1, got 0 > > pg_restore: *** aborted because of error > > Hm. Looking at the code, this appears to be an unexpected-EOF kind of > error (it expected to be able to read 1 more byte of data, and there > wasn't any). > > > Jun 10 14:24:19 vault pgqv[16995]: [242528] DEBUG: query: > Insert Into > > dump_blob_xref(oldOid, newOid) Values (1, 60983759); > > > I've done this twice, with two different db dumps, and both > have given me > > the same error. I'm wondering if that last line (with the > oldOid value of > > 1) is significant. > > I think the "1" is coincidental. It does seem that there is something > broken about the format of the dump file though. What version pg_dump > were you using, exactly? > > Other things to check would include accidental truncation or > corruption > of the dump file (eg, copying it onto a Windows machine might > result in > newline conversion, which would be bad). > > Philip, any other ideas where to look? > > regards, tom lane >
В списке pgsql-general по дате отправления: