From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Wyatt Alt <wyatt(dot)alt(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: cache lookup failed dropping public schema with trgm index |
Date: | 2023-08-28 02:15:28 |
Message-ID: | ZOwDQLV8W8qvfsU5@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Zhijie Hou (Fujitsu) | 2023-08-28 05:39:24 | RE: BUG #18055: logical decoding core on AllocateSnapshotBuilder() |
Previous Message | Heikki Linnakangas | 2023-08-27 20:24:59 | Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG |