Re: BUG #15627: libpq memory leak - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15627: libpq memory leak
Date
Msg-id 25171.1549818187@sss.pgh.pa.us
Whole thread Raw
In response to BUG #15627: libpq memory leak  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #15627: libpq memory leak  (Sergey Ivanov <icegood1980@gmail.com>)
List pgsql-bugs
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


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15627: libpq memory leak
Next
From: Sergey Ivanov
Date:
Subject: Re: BUG #15627: libpq memory leak