Re: memory leak in libpq , definitely lost: 200 bytes in 1 blocks, indirectly lost: 2,048 bytes in 1 blocks ...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: memory leak in libpq , definitely lost: 200 bytes in 1 blocks, indirectly lost: 2,048 bytes in 1 blocks ...
Дата
Msg-id 32026.1476110644@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: memory leak in libpq , definitely lost: 200 bytes in 1 blocks, indirectly lost: 2,048 bytes in 1 blocks ...  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-bugs
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 10/10/2016 12:38 PM, Simplex wrote:
>> } Repeat several times to get the leak

> I was not able to reproduce this.

I was able to reproduce it, or at least something that looks similar,
after a good deal of fooling around.  I needed:

* SSL turned on
* server recovering from crash, so that it rejects at least one connection
  attempt with "the database system is starting up"

This causes the successful PQreset call to leave an async result behind
containing the earlier connection rejection message.  That might or might
not be a logic bug in PQreset, but it doesn't really seem all that wrong.
But then the PQexec calls PQsendQueryStart which cavalierly resets
conn->result to NULL, leaking the async result.  I fixed PQsendQueryStart
to use pqClearAsyncResult which is less cavalier, and then I couldn't
reproduce the leak anymore.

Interestingly, I couldn't make it happen (ie get to PQsendQueryStart with
a non-null result) without valgrind active on the client --- so there's
some timing considerations involved too, apparently.

            regards, tom lane

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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: memory leak in libpq , definitely lost: 200 bytes in 1 blocks, indirectly lost: 2,048 bytes in 1 blocks ...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Query available indexes via jdbc meta data does not work any more in PostgreSQL 9.6.0