agora inbox for pljava-dev@postgresql.orghelp / color / mirror / Atom feed
[Pljava-dev] TupleDesc reference leak 2+ messages / 0 participants [nested] [flat]
* [Pljava-dev] TupleDesc reference leak @ 2012-06-21 06:52 2012-06-21 10:51 ` [Pljava-dev] TupleDesc reference leak 0 siblings, 1 reply; 2+ messages in thread From: @ 2012-06-21 06:52 UTC (permalink / raw) Hi, A customer ran into the issue reported through the bug tracker, #1010962: http://pgfoundry.org/tracker/?func=detail&atid=334&aid=1010962&group_id=1000038. If a PL/Java function takes a ResultSet as argument, you get warnings like: WARNING: TupleDesc reference leak: TupleDesc 124e120 (139824,-1) still referenced Grepping through the source, there seems to be two places where PL/Java gets a reference to a TupleDesc by calling lookup_rowtype_tupdsc(), but fails to release it. One is in HeapTupleHeader.c: > jobject HeapTupleHeader_getTupleDesc(HeapTupleHeader ht) > { > return TupleDesc_create( > lookup_rowtype_tupdesc( > HeapTupleHeaderGetTypeId(ht), > HeapTupleHeaderGetTypMod(ht))); > } This is the one that's leaking in the test case posted in the bug tracker. Fortunately, this is easy to fix. TupleDesc_create() creates a copy of the tuple descriptor, so we just need to release it after the call. Patch attached. The other is in Type.c, in Type_fromOid function: > if(typeClass != 0) > { > TupleDesc tupleDesc = lookup_rowtype_tupdesc_noerror(typeId, -1, true); > type = (Type)UDT_registerUDT(typeClass, typeId, typeStruct, tupleDesc, false); > JNI_deleteLocalRef(typeClass); > goto finally; > } I'm not sure what to do about that one. UDT_registerUDT() puts the TupleDesc Reference to a field in the UDT instance it creates. It's not clear to me what the lifecycle of that instance is. If we just created a copy of the TupleDesc, would we leak memory? Can the UDT object persist over transactions, in which case it holds a dangling pointer to the TupleDesc? Anyway, please apply the attached patch, at least. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-tupledesc-leak-1.patch Type: text/x-diff Size: 1077 bytes Desc: not available URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20120621/325cd43f/attachment.bin; ^ permalink raw reply [nested|flat] 2+ messages in thread
* [Pljava-dev] TupleDesc reference leak 2012-06-21 06:52 [Pljava-dev] TupleDesc reference leak @ 2012-06-21 10:51 ` 0 siblings, 0 replies; 2+ messages in thread From: @ 2012-06-21 10:51 UTC (permalink / raw) Hi Heikki, Heikki Linnakangas <heikki.linnakangas at enterprisedb.com> writes: > The other is in Type.c, in Type_fromOid function: > I'm not sure what to do about that one. UDT_registerUDT() puts the > TupleDesc Reference to a field in the UDT instance it creates. It's > not clear to me what the lifecycle of that instance is. If we just > created a copy of the TupleDesc, would we leak memory? Can the UDT > object persist over transactions, in which case it holds a dangling > pointer to the TupleDesc? I'll have to take a closer look at that later. Hence I have not closed the bug. > Anyway, please apply the attached patch, at least. Done. Thank you. -- Johann Oskarsson http://www.2ndquadrant.com/ |[] PostgreSQL Development, 24x7 Support, Training and Services --+-- | Blog: http://my.opera.com/myrkraverk/blog/ ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2012-06-21 10:51 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2012-06-21 06:52 [Pljava-dev] TupleDesc reference leak 2012-06-21 10:51 `
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox