Re: pg_dump and large files - is this a problem?
От | Bruce Momjian |
---|---|
Тема | Re: pg_dump and large files - is this a problem? |
Дата | |
Msg-id | 200210250138.g9P1c0M14062@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump and large files - is this a problem? ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>) |
Ответы |
Re: pg_dump and large files - is this a problem?
|
Список | pgsql-hackers |
Zeugswetter Andreas SB SD wrote: > > > 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? Also, I have the open item: Fix AIX + Large File + Flex problem Is there an AIX problem with Flex? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: