Re: pg_dump and large files - is this a problem?
От | Bruce Momjian |
---|---|
Тема | Re: pg_dump and large files - is this a problem? |
Дата | |
Msg-id | 200210232201.g9NM1vf28983@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump and large files - is this a problem? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > First we need to decide what we want to happen and after that think about > > how to implement it. Given sizeof(off_t) > sizeof(long) and no fseeko(), > > we have the following options: > > It seems obvious to me that there are no platforms that offer > sizeof(off_t) > sizeof(long) but have no API for doing seeks with off_t. > That would be just plain silly. IMHO it's acceptable for us to fail at > configure time if we can't figure out how to seek. I would certainly be happy failing at configure time, so we know at the start what is broken, rather than failures during restore. > The question is *which* seek APIs we need to support. Are there any > besides fseeko() and fgetpos()? What I have added is BSD/OS specific because only on BSD/OS do I know fpos_t and off_t are the same type. If we come up with other platforms, we will have to deal with it then. -- 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 по дате отправления: