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 | 43935F75.1070503@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_restore [archiver] file offset in dump file is too (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
Bruce Momjian wrote: >Andrew Dunstan wrote: > > >>Tom Lane wrote: >> >> >> >>>> While Win32 supports 64-bit files, the MinGW API does not, >>>> meaning we have to build an fseeko replacement on top of the >>>> Win32 API, and we have to make sure MinGW handles it. >>>> >>>> >>>> >>>> >>>Wouldn't it be better to lobby the MinGW folk to fix their problem? >>>Or even help them with it? I can't see the rationale for implementing >>>a workaround that helps only us. >>> >>> >>> >>> >>> >>> >>There is a library available from the gnuwin32 project that advertises >>fseeko and fseeko64. So we probably have a choice of requiring this >>library or doing it ourselves. >> >>see http://gnuwin32.sourceforge.net/packages/libgw32c.htm >> >> > >OK, updated: > > o Add long file support for binary pg_dump output > > While Win32 supports 64-bit files, the MinGW API does not, > meaning we have to build an fseeko replacement on top of the > Win32 API, and we have to make sure MinGW handles it. Another > option is to wait for the MinGW project to fix it, or use the > code from the LibGW32C project as a guide. > >My bet is that the license for LibGW32C might require us to use it as a >guide rather than the code itself. > > > [after examining source] It's LGPL. But basically it just uses fsetpos() just like ours does. So maybe a little adjustment to our config so we can use ours in a 64 bit manner would be the way to go. cheers andrew
В списке pgsql-hackers по дате отправления: