Re: BUG #6233: pg_dump hangs with Access Violation C0000005 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Date
Msg-id 9004.1317787610@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6233: pg_dump hangs with Access Violation C0000005  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses 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>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Next
From: Thomas Kellerer
Date:
Subject: Re: [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe