Re: pg_restore [archiver] file offset in dump file
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
I think you're on to something, Magnus. From a Windows cmd prompt
the size matches Linux:
11/01/2005 12:35 PM 40,874,747,876 dtr.dump
From an msys command prompt, ti does not look good:
-rw-r--r-- 1 Administ Administ 18446744071634626532 Nov 1 12:35
dtr.dump
I believe we got the latest msys and mingw when we set up the
PostgreSQL build environment, but that was a couple months ago.
-Kevin
"Magnus Hagander" <mha@sollentuna.net> >>>
Windows certainly supports large files. I don't see why we wouldn't pick
this up in autoconf, perhaps the mingw libraries don't?
Definitly worth investigating
Import Notes
Resolved by subject fallback