Re: lookup_rowtype_tupdesc considered harmful - Mailing list pgsql-hackers

From Tom Lane
Subject Re: lookup_rowtype_tupdesc considered harmful
Date
Msg-id 29393.1136904470@sss.pgh.pa.us
Whole thread Raw
In response to Re: lookup_rowtype_tupdesc considered harmful  (Neil Conway <neilc@samurai.com>)
Responses Re: lookup_rowtype_tupdesc considered harmful  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
I had a further thought about this.  What we're really talking about
here is a reference-counted TupleDesc structure: it's got no necessary
connection to TypeCacheEntry at all.  And in fact there are other places
in the system that could use such a facility.  For instance,
TupleTableSlot has a "shouldFreeDesc" flag that sort of allows partial,
one-way sharing of descs between slots, but it would work a lot better
if the descriptors contained reference counts instead.  And it might be
worth insisting that users of a relation tupledesc from the relcache
increment its refcount while they use it --- that would get rid of some
rather shaky assumptions about when it's OK to free the tupledesc during
relcache updates.

I'm thinking it might be worth the cost to just add a refcount field to
the standard tupleDesc struct.  (We don't need an isdead flag: more
elegantly, just include the TypeCacheEntry's own reference to the
tupdesc in the refcount.)  Add macros IncrTupleDescRefCount and
DecrTupleDescRefCount, the latter freeing the struct if the count
goes to zero, and voila.

I'm not quite sure whether the tupledesc creation routines should
initialize the count to zero or to one, but otherwise it all seems
pretty clear.  Thoughts?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: current_setting returns 'unset'
Next
From: Tom Lane
Date:
Subject: Re: current_setting returns 'unset'