Re: type cache cleanup improvements

On 13/9/2024 01:38, Alexander Korotkov wrote:
> I've tried to implement handling of concurrent invalidation similar to
> commit fdd965d074.  However that appears to be more difficult that I
> thought, because for some datatypes like arrays, ranges etc we might
> need fill the element type and reference it.  So, I decided to
> continue with the current approach but borrowing some ideas from
> fdd965d074.  The revised patchset attached.
Let me rephrase the issue in more straightforward terms to ensure we are 
all clear on the problem:
The critical problem of the typcache lookup on not-yet-locked data is 
that it can lead to an inconsistent state of the TypEntry, potentially 
causing disruptions in the DBMS's operations, correct?
Let's exemplify this statement. By filling typentry's lt_opr, eq_opr, 
and gt_opr fields, we access the AMOPSTRATEGY cache. One operation can 
successfully fetch data from the cache, but another can miss data and 
touch the catalogue table, causing invalidations. In this case, we can 
get an inconsistent set of operators. Do I understand the problem 
statement correctly?

If this view is correct, your derived approach should work fine if all 
necessary callbacks are registered. I see that at least AMOPSTRATEGY and 
PROCOID were missed at the moment of the typcache initialization.

-- 
regards, Andrei Lepikhov