On Tue, 4 Apr 2006, Peter Eisentraut wrote:
> We seem to have identified a prepared statement leak in the JDBC driver. The
> actual application runs through Hibernate, so we have attempted to isolate
> the problem here. In the field, the problem causes the PostgreSQL server to
> run out of memory in linear time.
>
> The two prerequisites for this problem to appear are:
>
> 1. PreparedStatement objects are rebound with different types, which causes
> the JDBC driver to replan the statement.
>
> 2. Batches are used.
>
To cleanup prepared statements the driver records a reference to a query
object in response to the ParseComplete message. The problem in this case
was that since the driver sends multiple Parse messages before a Sync,
when the driver receives the first ParseComplete message the query object
now contains a reference to the latest parsed statement, not the first.
So it was only cleaning up the last parsed statement not all of them.
I believe the attached patch fixes this, but I'd like Oliver to take a
look at it. I've made included the original statement name in the list of
things available to the ParseComplete receiver so it can record the
correct original statement to be destroyed.
An ideal driver would keep only two prepared plans around, one for each
set of parameter types, but that's more complicated and for a rather
unusual situation.
Kris Jurka
