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
>
