Re: pg_dump and large files - is this a problem?
| От | Tom Lane |
|---|---|
| Тема | Re: pg_dump and large files - is this a problem? |
| Дата | |
| Msg-id | 23495.1035303777@sss.pgh.pa.us обсуждение |
| Ответ на | Re: pg_dump and large files - is this a problem? (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Ответы |
Re: pg_dump and large files - is this a problem?
|
| Список | 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 по дате отправления: