Re: BUG #6233: pg_dump hangs with Access Violation C0000005

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Дата
Msg-id 9004.1317787610@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #6233: pg_dump hangs with Access Violation C0000005  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: BUG #6233: pg_dump hangs with Access Violation C0000005  (Craig Ringer <ringerc@ringerc.id.au>)
Re: BUG #6233: pg_dump hangs with Access Violation C0000005  ("Pavel Holec" <holec@email.cz>)
Список pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of mar oct 04 22:04:29 -0300 2011:
>> Hmm.  I can see how that would happen if you're using one of the Windows
>> environments wherein malloc's done inside libpq have to be free'd inside
>> libpq.  (The PQExpBuffer support code is in libpq...)

> Isn't this the kind of thing that you have to enable explicitly?

I'm looking at our docs for PQfreemem:

    Frees memory allocated by libpq, particularly PQescapeByteaConn,
    PQescapeBytea, PQunescapeBytea, and PQnotifies. It is
    particularly important that this function, rather than free(),
    be used on Microsoft Windows. This is because allocating memory
    in a DLL and releasing it in the application works only if
    multithreaded/single-threaded, release/debug, and static/dynamic
    flags are the same for the DLL and the application. On
    non-Microsoft Windows platforms, this function is the same as
    the standard library function free().

I have no idea how accurate or complete that third sentence is;
but perhaps the OP is trying to use a libpq.dll that was built
separately from his pg_dump executable?

            regards, tom lane

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Следующее
От: Thomas Kellerer
Дата:
Сообщение: Re: [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe