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
