Re: pg_dump and large files - is this a problem? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump and large files - is this a problem?
Date
Msg-id 23495.1035303777@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump and large files - is this a problem?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: pg_dump and large files - is this a problem?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: pg_dump and large files - is this a problem?
Next
From: Bruce Momjian
Date:
Subject: Re: pg_dump and large files - is this a problem?