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
Re: BUG #6233: pg_dump hangs with Access Violation C0000005 |
Список | 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 по дате отправления: