Re: BUG #15627: libpq memory leak

Поиск
Список
Период
Сортировка
От Sergey Ivanov
Тема Re: BUG #15627: libpq memory leak
Дата
Msg-id CAJCbrz47ex2LD3AXXi=xZUxh2jJsnzseHrW_vCY8qh+z7f3amg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #15627: libpq memory leak  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Thanks Tom. My fault. Hasn't closed PGRES_TUPLES_OK last empty record in single row mode output

вс, 10 февр. 2019 г. в 19:03, Tom Lane <tgl@sss.pgh.pa.us>:
PG Bug reporting form <noreply@postgresql.org> writes:
> PQisBusy has memory leak with next valgrind stack:

>   1: malloc in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
>   2: PQmakeEmptyPGresult in
> /opt/src/postgres/src/interfaces/libpq/fe-exec.c:146
>   3: getRowDescriptions in
> /opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:492
>   4: pqParseInput3 in
> /opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:293
>   5: parseInput in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1747
>   6: PQisBusy in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1764

I don't believe this is actually a leak: what is happening is that
we're collecting the query result that will eventually be returned
by PQgetResult.  If the calling program never calls PQgetResult
after PQisBusy, then tools like valgrind might claim that's a leak,
but the claim has nothing to do with reality.

If you think there's a real problem here, please show a self-contained
test case that causes steady increase in memory consumption.

                        regards, tom lane


--
Kind regards,
Sergey Ivanov

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15627: libpq memory leak
Следующее
От: David Rowley
Дата:
Сообщение: Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name