Обсуждение: BUG #4578: Not releaseing memory from PQmakeEmptyPGresult when calling PQisBusy
BUG #4578: Not releaseing memory from PQmakeEmptyPGresult when calling PQisBusy
От
"Sven Almgren"
Дата:
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