Re: pg_restore [archiver] file offset in dump file - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: pg_restore [archiver] file offset in dump file
Date
Msg-id 43680D4E0200002500000402@gwmta.wicourts.gov
Whole thread Raw
List pgsql-hackers
I am sure I set binary mode.  Even with that and an identical
file length, I figured I should confirm a good transfer before
posting; hence the md5sum on both sides.

Both sides were built from the source.  Here at home I don't
have the info on what configure switches were used, but I did
both the Linux and Windows builds with the same switches
except that Linux had something like --with-python, and I
couldn't get that to work on Windows.  The other switches
(used on both) included something like --enable-debug and
--enable-integer-timestamp.  I'm pretty sure there was one
more, but without my notes, I just can't remember what it
was.

One thing that I suspect might be a cause is the difficulty in
getting whole Windows environment set up correctly with
msys, etc.  I struggled a bit with bison, flex, and zlib -- so it
wouldn't shock me to find I have something wrong there.  Is
there anything in particular to check to confirm or disprove
that?

In case it matters, I also had a text dump of just the schema,
which I modified to alter a bytea column which already had
compression from the application code EXTERNAL.  I applied
the portion up to the view declarations, then applied the -Fc
dump (the one that is failing) with -a.  The same procedure
was followed on both Linux and Windows.

On Linux the pg_restore -Fc -a went fine, I applied the rest
of the schema dump, ran an analyze, and put the machine
back into use.  Nothing unusual happened, and index builds
and analyze ran in the normal amount of time, so I assume
that all is fine, although I haven't reviewed the tables closely.

-Kevin

>>> Tom Lane <tgl@sss.pgh.pa.us>  >>>
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> File dumped from 8.1beta3 using pg_dump -Fc on Linux box.
> This dump restored successfully onto 8.1RC1 on Linux box.
> File FTP'd to Windows box; attempt to restore onto 8.1RC1 fails with:
> pg_restore [archiver] file offset in dump file is too large

[ itch... ] This sure as heck sounds like the file was corrupted during
the FTP transfer.  Did you remember to select binary transfer mode?

> On Windows, the file size and md5sum -b result is identical.

That observation does seem like evidence against my theory, but ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Adrian Maier
Date:
Subject: Re: Call for port reports
Next
From: Simon Riggs
Date:
Subject: Re: Reducing the overhead of NUMERIC data