Hi Dave,
I have tested the patch from you, and it does make the perfmon graph
less steep. I am applying the patch to CVS.
Regarding the call to PGgetisnull: My mistake! I forgot to remove it,
thanks for pointing it out.
Regards
Anoop
-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Dave Page
Sent: Friday, July 15, 2005 7:06 PM
To: pgsql-odbc@postgresql.org
Cc: Anoop Kumar
Subject: [ODBC] Leak repairs
Hi Anoop,
I've spend a while (too long really!) tracking down the memory leaks
we've been seeing in the libpq driver. The code below is enough to see
the problems I've observed using perfmon monitoring the process's
private bytes value.
The attached patch fixes 2 leaks, each of which noticably reduce the
angle of the perfmon trace, however it's not quite flat yet, and my eyes
have gone blurry from looking! It seems to be leaking about 1Kb/per
SQLExecute/SQLFreeStmt (it was 4Kb when I started). It also removes an
unnecessary call to PQgetisnull that I noticed.
I haven't applied any of this to CVS - I'll leave that to you if you're
happy with it.
#include <windows.h>
#include <sqlext.h>
#include <stdio.h>
int main(void)
{
HENV hEnv = NULL;
HDBC hDBC = NULL;
HSTMT hStmt = NULL;
UCHAR szDSN[SQL_MAX_DSN_LENGTH] = "psqlodbc-libpq";
UCHAR szUID[64] = "postgres";
UCHAR* szPasswd = NULL;
UCHAR szSqlStr[] = "SELECT 1";
RETCODE retcode;
long loop = 0;
SQLAllocEnv (&hEnv);
SQLAllocConnect (hEnv, &hDBC);
retcode = SQLConnect (hDBC, szDSN, SQL_NTS, szUID, SQL_NTS,
szPasswd, SQL_NTS);
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO)
{
while(loop < 100000)
{
retcode = SQLAllocStmt (hDBC, &hStmt);
retcode = SQLPrepare (hStmt, szSqlStr, sizeof (szSqlStr));
retcode = SQLExecute (hStmt);
SQLFreeStmt (hStmt, SQL_DROP);
loop++;
}
SQLDisconnect (hDBC);
}
SQLFreeConnect (hDBC);
SQLFreeEnv (hEnv);
return 0;
}
Regards, Dave.
