Re: pg_dump and large files - is this a problem?

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > However, since we don't know if we support any non-integral off_t
> > platforms, and because a configure test would require us to have two
> > code paths for with/without integral off_t, I suggest we apply my
> > version of Philip's patch and let's see if everyone can compile it
> > cleanly.
> 
> Actually, it looks to me like configure will spit up if off_t is not
> an integral type:
> 
>  /* Check that off_t can represent 2**63 - 1 correctly.
>     We can't simply define LARGE_OFF_T to be 9223372036854775807,
>     since some C++ compilers masquerading as C compilers
>     incorrectly reject 9223372036854775807.  */
> #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
>   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
>                && LARGE_OFF_T % 2147483647 == 1)
>               ? 1 : -1];
> 
> So I think we're wasting our time to debate whether we need to support
> non-integral off_t ... let's just apply Bruce's version and wait to
> see if anyone has a problem before doing more work.

I am concerned about one more thing.  On BSD/OS, we have off_t of quad
(8 byte), but we don't have fseeko, so this call looks questionable:
if (fseeko(AH->FH, tctx->dataPos, SEEK_SET) != 0)

In this case, dataPos is off_t (8 bytes), while fseek only accepts long
in that parameter (4 bytes).  When this code is hit, a file > 4 gigs
will seek to the wrong offset, I am afraid.  Also, I don't understand
why the compiler doesn't produce a warning.

I wonder if I should add a conditional test so this code is hit only if
HAVE_FSEEKO is defined.  There is alternative code for all the non-zero
fseeks.

Comments?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073