Re: lookup_rowtype_tupdesc considered harmful
От | Tom Lane |
---|---|
Тема | Re: lookup_rowtype_tupdesc considered harmful |
Дата | |
Msg-id | 29393.1136904470@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: lookup_rowtype_tupdesc considered harmful (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: lookup_rowtype_tupdesc considered harmful
|
Список | 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 по дате отправления: