Re: pg_restore fails with a custom backup file
От | Magnus Hagander |
---|---|
Тема | Re: pg_restore fails with a custom backup file |
Дата | |
Msg-id | 20061218143937.GA6593@svr2.hagander.net обсуждение исходный текст |
Ответ на | Re: pg_restore fails with a custom backup file ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>) |
Ответы |
Re: pg_restore fails with a custom backup file
Re: pg_restore fails with a custom backup file |
Список | pgsql-hackers |
On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote: > > >Win32 does not implement fseeko() and ftello(). So I think it limit to > >handle a 2GB file. Is this a specification? > > Yes, Magnus-san suggested the problem. It is present TODO. The entire > adjustment was still difficult though I had tried it. SetFilePointer might > be able to be saved. However, I think it might be an attempt of 8.3... I've been looking at a fix for this, and I think I have it. The solution looks to be to redefine off_t to 64-bit (the standard headers *always* define it as 32-bit, and there is no way to change that - at least not that I can find). I have the fix made for just bin/pg_dump for now (in pg_dump.h), and I'm testing that. (So far only on MSVC builds) A question though - is there any *gain* from using 64-bit offsets in the actual backend? The change could of course be done in port.h, but that will affect the whole backend (and require a few more functions than just fseeko/ftello to be redefined) which could have larger consequences. So - provided that this works after my test is completed, is the better place to do this for just pg_dump/pg_restore, or attempt to do it for the whole backend? //Magnus
В списке pgsql-hackers по дате отправления: