On Tue, Aug 22, 2023 at 11:45:58AM -0700, Andres Freund wrote:
> It's not quite that, I think. Whether it fails or succeeds depends on the
> state of the system caches. The dependencies lead to the equivalent of
> ALTER OPERATOR FAMILY ... USING ... DROP
> being performed, before dropping the index.
>
> I think there are at least three levels of problems here:
>
> - I don't think we currently properly force index relcache entries to be
> invalidated when the relevant opfamily changes
>
> - LookupOpclassInfo() doesn't have *any* invalidation support, so even if we
> were to perform invalidation, we'd still return a potentially stale
> entry. The function says:
>
> * Note there is no provision for flushing the cache. This is OK at the
> * moment because there is no way to ALTER any interesting properties of an
> * existing opclass --- all you can do is drop it, which will result in
> * a useless but harmless dead entry in the cache.
>
> But that's not true (amymore?), because it does do pg_amproc lookups, and
> they *can* change.
>
> - Minor: Even if you force LookupOpclassInfo() to perform lookups again, it
> doesn't work, because when an amproc entry doesn't exist anymore, the old
> value in opcentry->supportProcs[i] survives, because nothing resets it.
Another thing: we also need to think harder about
RelationReloadIndexInfo() which is the cheap path for cache reload for
the index information. This is quite different from rd_options,
though, because we are going to need an extra facility to look at the
pg_attribute tuples for the indexes to get access to the new option
options? We touch that a bit in RelationBuildTupleDesc(), but not in
this cheap reload path. This is going to require more infrastructure,
at quick glance..
--
Michael