Skip site navigation (1) Skip section navigation (2)

Re: Memory leaks using refcursors

From: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
To: "Dave Cramer" <davec(at)postgresintl(dot)com>, "PostgreSQL JDBC" <pgsql-jdbc(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Memory leaks using refcursors
Date: 2007-01-18 17:42:21
Message-ID: 1d4e0c10701180942i60edff8bt914258ab0e1761ac@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Hi again,

In fact, there is still a remaining problem. People who developed this
application sometimes commit the transaction before closing the result
set in their code.
With the current driver, it's not a problem as it didn't close the
cursor at all so the cursor is closed at the end of the transaction
and that's all.

But with this patch, we have the following case:
- begin
- open result set -> open the cursor
- commit -> close the cursor
- close the result set -> try to close the cursor -> exception and
backend in an error state if autocommit is false

They fixed the order of commit/close in their application but IMHO,
it's a bad idea to introduce this sort of regression.

A try/catch is probably not a good idea because it leaves the backend
in an error state if the CLOSE query is executed in a transaction (if
autocommit is false for example).

Any ideas on how we can solve this problem? I can't find any way to
check if a cursor is still alive without throwing an error.

--
Guillaume

In response to

Responses

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2007-01-18 21:54:36
Subject: Re: Default numeric scale of zero in JDBC?
Previous:From: Todd ShoemakerDate: 2007-01-18 17:05:51
Subject: Re: Default numeric scale of zero in JDBC?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group