Re: pg_restore fails with a custom backup file

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: pg_restore fails with a custom backup file
Дата
Msg-id 458708A0.5090700@hagander.net
обсуждение исходный текст
Ответ на Re: pg_restore fails with a custom backup file  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pg_restore fails with a custom backup file  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
>> I suspect we might need to create a pg_off_t type or some such gadget.
>>
>> Bleah.
>>
>> But it does need to be fixed.
> 
> Bummer. That might be what's needed, but I'm going to at least try to
> find some neater way first. I wonder why it didn't happen on MSVC...

Hmm. This was even worse than I thought :-(

I got it building most of the way by following Andrews suggestion and
greating a pgoff_t, just to check it out. That done, it seems that mingw
doesn't include these 64-bit functions in their import library *at all*.
That gives us basically two options that I can see, to proceed:

1) Set up pg_dump* to dynamically load these functions from msvcrt.dll
at startup. This will require a different codepath from the MSVC build
of course, since Microsoft have been shipping these functions in their
libraries since NT4. Should work, but nor particularly pretty.

2) Just say that the mingw compiled versions of pg_dump* can't deal with
2Gb+ files. IIRC, we've built pg_dump with both the "new vc build
system" on VS2005 and with the "old win32.mak style build system" with
VC++ 6.0, so if we're comfortable enough with that we could just ship
binaries built with VC++ for those utilities (even if we don't go to
shipping completely MSVC built binaries for 8.3).


Thoughts on these options?

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: effective_cache_size vs units
Следующее
От: "Simon Riggs"
Дата:
Сообщение: Re: Dirty pages in freelist cause WAL stuck