Skip site navigation (1) Skip section navigation (2)

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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,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 22:19:32
Message-ID: Pine.LNX.4.44.0210291840290.2006-100000@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Zeugswetter Andreas SB SD writes:

> > 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.

I think the problem is more accurately described thus:  Flex generated
files include <stdio.h> before "postgres.h" due to the way it lays out the
code in the output.  stdio.h does something which prevents switching to
the large file model later on in postgres.h.  (This manifests itself in
unistd.h, but unistd.h itself is not the problem per se.)

The proposed fix was to include the flex output in some other file (such
as the corresponding grammar file) rather than to compile it separately.
The patch just needs to be tried out.

Peter Eisentraut   peter_e(at)gmx(dot)net

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-10-29 22:21:27
Subject: Re: float output precision questions
Previous:From: Peter EisentrautDate: 2002-10-29 22:19:22
Subject: Re: string freeze

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group