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 = 1785996817BTW, the file size is: 2361910772 bytes
Mike Charnoky
Tom Lane wrote:
Mike Charnoky <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
