Neil Conway <neilc@samurai.com> writes:
> On Mon, 2006-01-09 at 12:57 -0500, Tom Lane wrote:
>> I have not been able to think of an efficient way to make it work while
>> still handing back a simple TupleDesc pointer --- seems like we'd have
>> to contort the API somehow so that the "release" function can find the
>> reference count. Any thoughts about that?
> Perhaps the "release" function can just take a type OID. We could then
> use that to lookup the OID's typcache entry, which would be a convenient
> place to store the reference count (especially if we do generalized
> typcache invalidation, per discussion on -patches). That means two hash
> table lookups for each lookup/release pair, which isn't ideal but
> doesn't seem too bad.
Nah, I don't think this works. The problem is that after an inval,
you may have to provide an updated TupleDesc to new callers while
old callers still have open reference counts to the old TupleDesc.
The type OID isn't enough info to let you determine which generation
of TupleDesc is being released.
However, you might be able to adopt the same trick used in catcache.c:
the callers think they have pointers to HeapTuples and are unaware that
that is just a field of a larger struct. Add a reference count and a
"dead" flag, and a "magic" value for safety checking, and you've got it.
regards, tom lane
