| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Philip Warner" <pjw(at)rhyme(dot)com(dot)au>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Giles Lean" <giles(at)nemeton(dot)com(dot)au> |
| Subject: | Re: pg_dump and large files - is this a problem? |
| Date: | 2002-10-29 16:08:14 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961ED9@m0114.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> >> Yeah. AFAICS the only way around this is to avoid doing any I/O
> >> operations in the flex-generated files. Fortunately,
> that's not much
> >> of a restriction.
>
> > Unfortunately I do not think that is sufficient, since the problem is already
> > at the #include level. The compiler barfs on the second #include <unistd.h>
> > from postgres.h
>
> AIX is too stupid to wrap unistd.h in an "#ifndef" to protect against
> double inclusion? I suppose we could do that for them...
I guess that is exactly not wanted, since that would hide the actual
problem, namely that _LARGE_FILE_API gets defined (off_t --> 32bit).
Thus I think IBM did not protect unistd.h on purpose.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2002-10-29 16:49:58 | Re: Request for supported platforms |
| Previous Message | Jason Tishler | 2002-10-29 14:54:20 | Re: [HACKERS] Request for supported platforms |