Re: pg_restore [archiver] file offset in dump file is too
От | Andrew Dunstan |
---|---|
Тема | Re: pg_restore [archiver] file offset in dump file is too |
Дата | |
Msg-id | 436920F1.6050204@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_restore [archiver] file offset in dump file is too ("Magnus Hagander" <mha@sollentuna.net>) |
Ответы |
Re: pg_restore [archiver] file offset in dump file is too
Re: pg_restore [archiver] file offset in dump file is too |
Список | pgsql-hackers |
Magnus Hagander wrote: >>>Andrew Dunstan <andrew@dunslane.net> writes: >>> >>> >>>>Hmm. Windows reports an offset size of 4 bytes on a dump I >>>> >>>> >>just made >> >> >>>>... is that relevant? What governs it? >>>> >>>> >>>[ looks again... ] Hm, that is a 40Gb dump Kevin is >>> >>> >>complaining of, >> >> >>>isn't it. Do our Windows builds have LARGEFILE support? >>> >>> >>> >>I think from a cursory investigation the short answer is no, >>but they probably could. If so, that should definitely go on >>the TODO list. Windows gurus, any thoughts? >> >> > >Windows certainly supports large files. I don't see why we wouldn't pick >this up in autoconf, perhaps the mingw libraries don't? >Definitly worth investigating, no time for 8.1, so putting it on TODO >seems very good :-) > > There is no fseeko in the Windows libraries, nor any provision in the mingw headers that I can see for a 64 bit off_t. So we would need to roll our own to some extent - I think we need more than just a bit of configure cleverness. However, there is a Windows library routine to do a 64bit seek and return the file position, so we could fairly easily implement fseeko and ftello based on that. See http://msdn.microsoft.com/library/en-us/vclib/html/_crt__lseek.2c_._lseeki64.asp cheers andrew
В списке pgsql-hackers по дате отправления: