Re: BUG #15627: libpq memory leak

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(at)sss(dot)pgh(dot)pa(dot)us>:

> PG Bug reporting form <noreply(at)postgresql(dot)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