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

> > > The question is *which* seek APIs we need to support. Are there any
> > > besides fseeko() and fgetpos()?
> >
> > On AIX we have
> > int fseeko64 (FILE* Stream, off64_t Offset, int Whence);
> > which is intended for large file access for programs that do NOT
> > #define _LARGE_FILES
> >
> > It is functionality that is available if _LARGE_FILE_API is defined,
> > which is the default if _LARGE_FILES is not defined.
> >
> > That would have been my preferred way of handling large files on AIX
> > in the two/three? places that need it (pg_dump/restore, psql and backend COPY).
> > This would have had the advantage that off_t is not 64 bit in all other places
> > where it is actually not needed, no ?
>
> OK, I am focusing on AIX now. I don't think we can go down the road of
> saying where large file support is needed or not needed. I think for
> each platform either we support large files or we don't. Is there a way
> to have off_t be 64 bits everywhere, and if it is, why wouldn't we just
> enable that rather than poke around figuring out where it is needed?

if _LARGE_FILES is defined, off_t is 64 bits on AIX (and fseeko works).
The problem with flex is, that the generated c file does #include <unistd.h>
before we #include "postgres.h".
In this situation _LARGE_FILES is not defined for unistd.h and unistd.h
chooses to define _LARGE_FILE_API, those two are not compatible.

If a general off_t of 64 bits is no performance problem, we should focus
on fixing the #include <unistd.h> issue, and forget what I wanted/hinted.
Peter E. has a patch for this in his pipeline. I can give it a second try
tomorrow.

Sorry for the late answer, I am very pressed currently :-(
Andreas