Re: pg_restore and large files

Whoops, forget that last post. Here's the real data from gdb at the point prior
to failure of pg_restore:

Breakpoint 1, _PrintTocData (AH=0x8058fc0, te=0x80867e0, ropt=0x8058ee8)
at pg_backup_custom.c:471
471 if (fseeko(AH->FH, tctx->dataPos, SEEK_SET) != 0)
1: tctx->dataPos = -1927033749
(gdb) backtrace
#0 _PrintTocData (AH=0x8058fc0, te=0x80867e0, 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

Hope this is helpful. BTW, the dump file size is 2361910772 bytes. The last
valid dataPos before the crash was at 1785996918 (and the table being restored
was pretty big). So, it does look like a pg_restore bug and that dataPos is
being treated as an integer somewhere.

Mike Charnoky

Tom Lane wrote:
> Mike Charnoky <noky(at)nextbus(dot)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
>