Re: pg_dump and large files - is this a problem?
От | Bruce Momjian |
---|---|
Тема | Re: pg_dump and large files - is this a problem? |
Дата | |
Msg-id | 200210240145.g9O1jtF24959@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump and large files - is this a problem? (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: pg_dump and large files - is this a problem?
|
Список | pgsql-hackers |
Philip Warner wrote: > At 11:50 PM 23/10/2002 +0200, Peter Eisentraut wrote: > > >1. Disable access to large files. > > > >2. Seek in some other way. > > This gets my vote, but I would like to see a clean implementation (not huge > quantities if ifdefs every time we call fseek); either we write our own > fseek as Bruce seems to be suggesting, or we have a single header file that > defines the FSEEK/FTELL/OFF_T to point to the 'right' functions, where > 'right' is defined as 'most likely to generate an integer and which makes > use of the largest number of bytes'. We have to write another function because fsetpos doesn't do SEEK_CUR so you have to implement it with more complex code. It isn't a drop in place thing. > The way the code is currently written it does not matter if this is a 16 or > 3 byte value - so long as it is an integer. Right. What we are assuming now is that off_t can be seeked using whatever we defined for fseeko, which is incorrect in one, and now I hear more than one OS. -- 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 по дате отправления: