agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] ResultSetHandle and TupleDesc reference leak?
3+ messages / 0 participants
[nested] [flat]
* [Pljava-dev] ResultSetHandle and TupleDesc reference leak?
@ 2008-01-05 09:57
0 siblings, 2 replies; 3+ messages in thread
From: @ 2008-01-05 09:57 UTC (permalink / raw)
I have a program using ResultSetHandle and the first time a new
session uses the function, a warning pops up:
WARNING: TupleDesc reference leak: TupleDesc 0x750bcb0 (10307,-1)
still referenced
To be sure this wasn't my code, I used the exact example code shown in http://wiki.tada.se/display/pljava/Functions+returning+sets
.
# select * from javatest.listNonSupers();
WARNING: TupleDesc reference leak: TupleDesc 0x57aba8 (10307,-1)
still referenced
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd
| valuntil | useconfig
----------+----------+-------------+----------+-----------+----------
+----------+-----------
xxxxxxxx | 24576 | f | f | f | ********
| |
xxxxxxxx | 32768 | f | f | f | ********
| |
Everything seems to work properly, but the warning is somewhat
disconcerting.
Also, I've run into an issue using setSavePoint()... after the
function ends and the savepoint has been released, the results
returned in the resultsethandle cannot be used in anything except a
simple select. Using them as a select into or inside another function
fails, saying 'ERROR: buffer xxx is not owned by resource
owner TopTransaction.' If I don't use savepoints, I don't run into
this issue. My workaround has been to wrap the java function in a
plsql function and use commit/rollback there.
Thanks,
Lucas Madar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20080105/97f1ab87/attachment.html;
^ permalink raw reply [nested|flat] 3+ messages in thread
* [Pljava-dev] ResultSetHandle and TupleDesc reference leak?
@ 2008-01-18 05:36
parent:
1 sibling, 0 replies; 3+ messages in thread
From: @ 2008-01-18 05:36 UTC (permalink / raw)
I put in bug reports with patches on the pl/java website for these
issues. I think they are resolved, but the tupledesc patch might need to
be wrapped in some IFDEFs depending on what version of pgsql is being used.
- Lucas
Lucas Madar wrote:
> I have a program using ResultSetHandle and the first time a new
> session uses the function, a warning pops up: [tupledesc reference
> leak, ...]
^ permalink raw reply [nested|flat] 3+ messages in thread
* [Pljava-dev] ResultSetHandle and TupleDesc reference leak?
@ 2008-02-01 07:27
parent:
1 sibling, 0 replies; 3+ messages in thread
From: @ 2008-02-01 07:27 UTC (permalink / raw)
On Sat, 5 Jan 2008, Lucas Madar wrote:
> I have a program using ResultSetHandle and the first time a new session uses
> the function, a warning pops up:
>
> WARNING: TupleDesc reference leak: TupleDesc 0x750bcb0 (10307,-1) still
> referenced
>
I've applied your fix for this.
> Also, I've run into an issue using setSavePoint()... after the function
> ends and the savepoint has been released, the results returned in the
> resultsethandle cannot be used in anything except a simple select. Using
> them as a select into or inside another function fails, saying 'ERROR:
> buffer xxx is not owned by resource owner TopTransaction.' If I don't
> use savepoints, I don't run into this issue. My workaround has been to
> wrap the java function in a plsql function and use commit/rollback
> there.
>
I'm not so sure about this fix and I've left some further comments in the
tracker. I'll try and take a look at this next week, but with the 8.3
server release coming out this weekend we've got to push the 1.4 pljava
release out now.
Kris Jurka
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2008-02-01 07:27 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-01-05 09:57 [Pljava-dev] ResultSetHandle and TupleDesc reference leak?
2008-01-18 05:36 `
2008-02-01 07:27 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox