Re: type cache cleanup improvements

On 29/8/2024 11:01, Alexander Korotkov wrote:
> On Mon, Aug 26, 2024 at 11:26 AM Alexander Korotkov
>> Secondly, I'm not terribly happy with current state of type cache.
>> The caller of lookup_type_cache() might get already invalidated data.
>> This probably OK, because caller probably hold locks on dependent
>> objects to guarantee that relevant properties of type actually
>> persists.  At very least this should be documented, but it doesn't
>> seem so.  Setting of tupdesc is sensitive to its order of execution.
>> That feels quite fragile to me, and not documented either.  I think
>> this area needs improvements before we push additional functionality
>> there.
> 
> I see fdd965d074 added a proper handling for concurrent invalidation
> for relation cache. If a concurrent invalidation occurs, we retry
> building a relation descriptor.  Thus, we end up with returning of a
> valid relation descriptor to caller.  I wonder if we can take the same
> approach to type cache.  That would make the whole type cache more
> consistent and less fragile.  Also, this patch will be simpler.
I think I understand the solution from the commit fdd965d074.
Just for the record, you mentioned invalidation inside the 
lookup_type_cache above. Passing through the code, I found the only 
place for such a case - the call of the GetDefaultOpClass, which 
triggers the opening of the relation pg_opclass, which can cause an 
AcceptInvalidationMessages call. Did you mean this case, or does a wider 
field of cases exist here?

-- 
regards, Andrei Lepikhov