Chapman Flack <c...@anastigmatix.net> writes:
> There are some things about the life cycle of the common TupleDesc
> that I'm not 100% sure about.
> 1. In general, if you get one from relcache or typcache, it is
> reference-counted, right?
Tupdescs for named composite types should be, since those are
potentially modifiable by DDL. The refcount allows a stale tupdesc
to go away when it's no longer referenced anywhere.
Tupdescs for RECORD types are a different story: there's no way to
change them once created, so they'll live as long as the process
does (at least for tupdescs kept in the typcache). Refcounting
isn't terribly necessary in that case; and at least for the shared
tupdesc case, we don't do it, to avoid questions of modifying a
piece of shared state.
> 3. Is that shared case the only way you could see a non-refcounted
> TupleDesc handed to you by the typcache?
I'm not sure what happens for a non-shared RECORD tupdesc, but it
probably wouldn't be wise to assume anything either way.
> 5. When a constructed TupleDesc is blessed, the copy placed in the cache
> by assign_record_type_typmod is born with a refcount of 1. Assuming every
> later user of that TupleDesc plays nicely with balanced pin and release,
> what event(s), if any, could ever occur to decrease that initial 1 to 0?
That refcount is describing the cache's own reference, so as long as
that reference remains it'd be incorrect to decrease the refcount to 0.
regards, tom lane
