Re: TupleDesc refcounting - Mailing list pgsql-patches

From Tom Lane
Subject Re: TupleDesc refcounting
Date
Msg-id 28317.1150483848@sss.pgh.pa.us
Whole thread Raw
In response to Re: TupleDesc refcounting  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Automatic free space map filling
Next
From: Bruce Momjian
Date:
Subject: Re: [BUGS] [Win32] Problem with rename()