QR_Destructor should iterate, not recurse, chained result sets

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: pgsql-odbc(at)postgresql(dot)org
Subject: QR_Destructor should iterate, not recurse, chained result sets
Date: 2013-03-15 08:45:34
Message-ID: 5142DFAE.1060408@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

QR_Destructor() calls QR_close_result(), which free's all the resources
associated with the result set. It also calls QR_Destructor() on the
next result set in the chain. In other words, when you call
QR_Destructor() on the first result, it recurses to free all the chained
results.

That recursion is a problem. A chained result set occurs at least if you
use array binding; there is one chained result for each element in the
parameter array. ODBC applications typically use parameter arrays to
bulk insert data, in which case the parameter array can be very large.

I bumped into this in an application that bound over 10000 parameters in
a statement. That works otherwise, but 10000-level deep recursion
sometimes causes the application to run out of stack space. The funny
thing is that the recursion happens when the statement is free'd; other
operations don't recurse.

It's pretty obvious that QR_destructor/QR_close_result() should iterate,
not recurse, through the chained results. Patch attached. Aside from
avoiding running out of stack space, this speeds up freeing the
statement considerably.

I've also pushed this to my github repository at
https://github.com/hlinnaka/psqlodbc. I also added a test case for array
binding parameters to the master-with-testcases branch in the same
repository.

- Heikki

Attachment Content-Type Size
psqlodbc-avoid-recursion-in-SQLFreeHandle-2.patch text/x-diff 3.2 KB

Browse pgsql-odbc by date

  From Date Subject
Next Message Heikki Linnakangas 2013-03-15 11:20:58 Memory leak with SQLNumResultCols
Previous Message Heikki Linnakangas 2013-03-04 11:13:58 Re: speeding up inserts by pipelining