OK, I ran with gdb and here's what I got:
Breakpoint 1, _PrintTocData (AH=0x8058fc0, te=0x8086548, ropt=0x8058ee8)
at pg_backup_custom.c:471
471 if (fseeko(AH->FH, tctx->dataPos, SEEK_SET) != 0)
(gdb) backtrace
#0 _PrintTocData (AH=0x8058fc0, te=0x8086548, ropt=0x8058ee8)
at pg_backup_custom.c:471
#1 0x0804a98b in RestoreArchive (AHX=0x8058fc0, ropt=0x8058ee8)
at pg_backup_archiver.c:336
#2 0x0804a03e in main (argc=10, argv=0xbffff924) at pg_restore.c:366
#3 0x42015967 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) display tctx->dataPos
2: tctx->dataPos = 1785996817
BTW, the file size is: 2361910772 bytes
Mike Charnoky
Tom Lane wrote:
> Mike Charnoky <noky@nextbus.com> writes:
>
>>I am currently using PostgreSQL v7.3.4 on a RedHat 8.0 system (2.4.23 kernel)
>>using the ext3 filesystem. I am experiencing problems when performing a
>>pg_restore using a file which is 2.3G in size. The dump, which seemed to run
>>smoothly, was created using the -Fc option. When I perform the restore, the
>>following error occurs before the pg_restore fails:
>
>
>>pg_restore: [custom archiver] error during file seek: Invalid argument
>>pg_restore: *** aborted because of error
>
>
>>Why is this happening? The error comes from pg_backup_custom.c, it seems that
>>an fseeko() is failing (even though this is the way to support large
>>files).
>
>
> Hm, can you insert some debugging printout to show the offset value
> being passed to fseeko? That would let us eliminate one of pg_restore
> and the kernel as being at fault. Another thing that'd be useful is to
> run pg_restore under gdb with a breakpoint set at die_horribly, so that
> you could get a stack trace from the point of the failure.
>
> I am suspicious that it's a pg_restore bug and the problem has to do
> with manipulating file offsets as plain integers someplace. Not enough
> info yet to go searching, though.
>
> regards, tom lane
>
