Re: cache lookup failed dropping public schema with trgm index

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