On 12/14/21 18:03, Tom Lane wrote: > Tupdescs for RECORD types are a different story: ... 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.
Ok, that's kind of what I was getting at here: >> 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. ... >> what event(s), if any, could ever occur to decrease that initial 1 ... > > 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. In the case of a blessed RECORD+typmod tupdesc, *is* there any event that could ever cause the cache to drop that reference? Or is the tupdesc just going to live there for the life of the backend, its refcount sometimes going above and back down to but never below 1? That would fit with your "refcounting isn't terribly necessary in that case". If that's how it works, it's interesting having the two different patterns: if it's a shared one, it has refcount -1 and you never fuss with it and it never goes away; if it's a local one it has a non-negative refcount and you go through all the motions and it never goes away anyway. >> 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. If I'm reading this right, for the non-shared case, the copy that goes into the cache is made refcounted. (The copy you presented for blessing gets the assigned typmod written in it, and no change to its refcount field.) There's really just one thing I'm interested in assuming: *In general*, if I encounter a tupdesc with -1 refcount, I had better not assume much about its longevity. It might be in a context that's about to go away. If I'll be wanting it later, I had better defensively copy it into some context I've chosen. (Ok, I guess if it's a tupdesc provided to me in a function call, I can assume it is good for the duration of the call, or if it's part of an SPI result, I can assume it's good until SPI_finish.) But if I have gone straight to the typcache to ask for a RECORD tupdesc, and the one it gives me has -1 refcount, is it reasonable to assume I can retain a reference to that without the defensive copy? Regards, -Chap