Hi,
On 2023-08-21 19:27:19 -0400, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > On Mon, Aug 21, 2023 at 03:36:10PM -0700, Andres Freund wrote:
> >> It also seems to work without even involving a drop schema. Just dropping
> >> pg_trgm with cascade is sufficient.
>
> > FWIW, after a bisect I can see that 911e7020 is the origin of the
> > failure (`git bisect start b5d69b7 9e1c9f9` based on two merge-bases).
>
> Hmm. I see that 911e7020 modified pg_trgm's install script with
>
> +ALTER OPERATOR FAMILY gist_trgm_ops USING gist
> +ADD FUNCTION 10 (text) gtrgm_options (internal);
>
> I wonder whether that correctly adds a dependency to ensure the
> opfamily is dropped before the function.
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.
Greetings,
Andres Freund
