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

Re: Memory leaks using refcursors

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
Cc: "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-19 00:03:16
Message-ID: 212AA1E7-770A-4F24-B8DF-B11438F748F7@fastcrypt.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
On 18-Jan-07, at 12:42 PM, Guillaume Smet wrote:

> 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.

There's one important piece of information I believe might be  
relevant here.

The application is using XA. I'm not convinced that there isn't a  
subtle bug in the server's XA implementation that may be keeping  
track of the open cursor.

Under the covers this is using the unnamed cursor, and there is no  
close cursor being issued, The cursor is implicitly closed by opening  
another unnamed cursor.

I've asked Guillaume to test this hypothesis with his test case that  
does not use XA to see if the memory "leak" still exists without XA

Dave
>
> --
> Guillaume
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo(at)postgresql(dot)org so that  
> your
>       message can get through to the mailing list cleanly
>


In response to

Responses

pgsql-jdbc by date

Next:From: Guillaume SmetDate: 2007-01-19 13:26:55
Subject: Re: Memory leaks using refcursors
Previous:From: Oliver JowettDate: 2007-01-18 21:54:36
Subject: Re: Default numeric scale of zero in JDBC?

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