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
