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
