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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Pavel Holec <holec(at)email(dot)cz>, "'Craig Ringer'" <ringerc(at)ringerc(dot)id(dot)au>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Date: 2011-10-05 04:06:50
Message-ID: 9004.1317787610@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Basavaraj, Chethan (EXT-Other - IN/Bangalore) 2011-10-05 06:02:02 About - postgreswdinit.sql
Previous Message Alvaro Herrera 2011-10-05 03:28:36 Re: BUG #6233: pg_dump hangs with Access Violation C0000005