Re: Prepared statement leak
От | Kris Jurka |
---|---|
Тема | Re: Prepared statement leak |
Дата | |
Msg-id | Pine.BSO.4.63.0604041719380.13705@leary2.csoft.net обсуждение исходный текст |
Ответ на | Prepared statement leak (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Prepared statement leak
Re: Prepared statement leak |
Список | pgsql-jdbc |
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
Вложения
В списке pgsql-jdbc по дате отправления: