I wrote: > I'm finally getting back to looking at the problem of reference-counting > cached TupleDescs as was discussed in January. I had objected to the > last patch Neil posted: > http://archives.postgresql.org/pgsql-patches/2006-01/msg00243.php > on the grounds that it seemed too complicated. On looking at it > closely, I realize that a lot of the complexity comes from my insistence > that the ResourceOwner mechanism ought to warn about any tupdesc > references that haven't been explicitly released before transaction end.
After much thrashing I concluded that my original instinct was right and we really do want to insist on cleanup of tupdesc references during normal processing. The approach I tried to take effectively meant leaking tupdesc references until end of query, which is really bad news for SQL-language functions --- a function that grabs a tupdesc reference during plan startup would then accumulate a tupdesc reference during every invocation, leading to indefinite bloat in the ResourceOwner over a long query. So I ended up applying something pretty close to Neil's patch. I did modify it to not bother reference-counting tupdescs that aren't actually in any cache. I also fixed up TupleTableSlots to do reference-count processing if ExecSetSlotDescriptor is handed a reference-counted tupdesc (my assertion yesterday that this never happens was wrong), but not to bother cleaning up non-ref-counted descriptors. All in all, a lot of thrashing for only marginal improvement :-( regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq