Re: Memory leaks using refcursors
От | Dave Cramer |
---|---|
Тема | Re: Memory leaks using refcursors |
Дата | |
Msg-id | 127FFFA1-CF4F-4CC5-A6EA-23442E2E0C69@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: Memory leaks using refcursors ("Guillaume Smet" <guillaume.smet@gmail.com>) |
Ответы |
Re: Memory leaks using refcursors
|
Список | pgsql-jdbc |
Hi Guilluame On 19-Jan-07, at 8:26 AM, Guillaume Smet wrote: > Hi Dave, > > On 1/19/07, Dave Cramer <pg@fastcrypt.com> wrote: >> 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 > > Perhaps I was not clear when I explained the remaining problem. I > don't have any memory leak left. The attached file is a test case > which shows the new problem. You were exceptionally clear when you described the problem you are now having. Apparently I have not been clear. I don't believe the solution is for the result set to close the unnamed portal when it is closed. As you can see there is a catch-22 situation which you described clearly. I believe the problem is in the server's XA code somehow not closing unnamed parameters properly. If you could run the code I sent you and tell me if it causes a leak, then that will confirm it. Dave > > The commit is done before closing the resultset and so the close() > method can't find the portal which results in an exception (the portal > is closed on commit). > It's probably not something we should do but before there was no error > in this case and now it throws an exception which is not really clear > for the end user: > An exception has occured.ERROR: cursor "<unnamed portal 1>" does > not exist > org.postgresql.util.PSQLException: ERROR: cursor "<unnamed portal 1>" > does not exist > > -- > Guillaume > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend >
В списке pgsql-jdbc по дате отправления: