Thread: BUG #4578: Not releaseing memory from PQmakeEmptyPGresult when calling PQisBusy

The following bug has been logged online:

Bug reference:      4578
Logged by:          Sven Almgren
Email address:      sven@blocket.se
PostgreSQL version: 8.3.5
Operating system:   CentOS release 5.2 (Final)
Description:        Not releaseing memory from PQmakeEmptyPGresult when
calling PQisBusy
Details:

==14976== 4,480 (384 direct, 4,096 indirect) bytes in 2 blocks are
definitely lost in loss record 19 of 55
==14976==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==14976==    by 0x38FC80E194: PQmakeEmptyPGresult (in
/usr/lib64/libpq.so.5.1)
==14976==    by 0x38FC814BEC: (within /usr/lib64/libpq.so.5.1)
==14976==    by 0x38FC816031: (within /usr/lib64/libpq.so.5.1)
==14976==    by 0x38FC80D5AF: PQisBusy (in /usr/lib64/libpq.so.5.1)

Without specifying too much about our system we're running an asynchronous
system which will only process SQL results when it won't block, so we're
running PQisBusy alot and we think that it has something todo with some
funktion not checking if conn->result is already set, but we're not sure..

# rpm -qa|grep postgres
postgresql-libs-8.3.5-1PGDG.rhel5
postgresql-server-8.3.5-1PGDG.rhel5
postgresql-devel-8.3.5-1PGDG.rhel5
postgresql-8.3.5-1PGDG.rhel5
compat-postgresql-libs-4-2PGDG.rhel5_x86_64

"Sven Almgren" <sven@blocket.se> writes:
> ==14976== 4,480 (384 direct, 4,096 indirect) bytes in 2 blocks are
> definitely lost in loss record 19 of 55
> ==14976==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
> ==14976==    by 0x38FC80E194: PQmakeEmptyPGresult (in
> /usr/lib64/libpq.so.5.1)
> ==14976==    by 0x38FC814BEC: (within /usr/lib64/libpq.so.5.1)
> ==14976==    by 0x38FC816031: (within /usr/lib64/libpq.so.5.1)
> ==14976==    by 0x38FC80D5AF: PQisBusy (in /usr/lib64/libpq.so.5.1)

AFAICS this would be your own bug, ie neglecting to collect and
eventually PQclear the result after PQisBusy has returned false.

> Without specifying too much about our system ...

If you are not willing to provide a self-contained test case there is
very little anyone else can do here.

            regards, tom lane