From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Wyatt Alt <wyatt.alt@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: cache lookup failed dropping public schema with trgm index
Date: Mon, 28 Aug 2023 11:15:28 +0900
Message-ID: <ZOwDQLV8W8qvfsU5@paquier.xyz> (raw)
In-Reply-To: <20230822184558.4d5tfkiep2akbn24@awork3.anarazel.de>
References: <CAGem3qAM7M7B3DdccpgepRxuoKPd2Y74qJ5NSNRjLiN21dPhgg@mail.gmail.com>
<20230821223610.glmwmdsv2xofihiu@awork3.anarazel.de>
<ZOPrYNyJO95YItPp@paquier.xyz>
<2983696.1692660439@sss.pgh.pa.us>
<20230822184558.4d5tfkiep2akbn24@awork3.anarazel.de>
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, andres@anarazel.de, tgl@sss.pgh.pa.us, wyatt.alt@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: cache lookup failed dropping public schema with trgm index
In-Reply-To: <ZOwDQLV8W8qvfsU5@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox