Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 28 Aug 2023 11:15:28 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Wyatt Alt <wyatt.alt@gmail.com>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: cache lookup failed dropping public schema with trgm index
Message-ID: <ZOwDQLV8W8qvfsU5@paquier.xyz>
References: 
 <CAGem3qAM7M7B3DdccpgepRxuoKPd2Y74qJ5NSNRjLiN21dPhgg@mail.gmail.com>
 <20230821223610.glmwmdsv2xofihiu@awork3.anarazel.de>
 <ZOPrYNyJO95YItPp@paquier.xyz>
 <2983696.1692660439@sss.pgh.pa.us>
 <20230822184558.4d5tfkiep2akbn24@awork3.anarazel.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="wGv/GnRLoPzJ976+"
Content-Disposition: inline
In-Reply-To: <20230822184558.4d5tfkiep2akbn24@awork3.anarazel.de>
Archived-At: 
 <https://www.postgresql.org/message-id/ZOwDQLV8W8qvfsU5%40paquier.xyz>
Precedence: bulk


--wGv/GnRLoPzJ976+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> I think there are at least three levels of problems here:
>=20
> - I don't think we currently properly force index relcache entries to be
>   invalidated when the relevant opfamily changes
>=20
> - 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:
>=20
>  * 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.
>=20
>   But that's not true (amymore?), because it does do pg_amproc lookups, a=
nd
>   they *can* change.
>=20
> - Minor: Even if you force LookupOpclassInfo() to perform lookups again, =
it
>   doesn't work, because when an amproc entry doesn't exist anymore, the o=
ld
>   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

--wGv/GnRLoPzJ976+
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmTsA0AACgkQnvQgOdby
QH0iIxAAiwLrOZh5vCGlQ5BHRaYV1LVhIQQ5EJv7bK9hj2C8RZq01Nzac5tcZjhj
j0x3SiysE4BxKwFjkRo69zzS75E/wswNvpzNJMJEsmaNqX1SmCz6+L9EWv5tbhYW
GW2548Wu3TfxzrT2izwEFwKXsAjRZ4sEWQU+HdKL/2IBYp/KsI2pjTO70NL3P3nG
UBdAtvjnbD0HZ/Lj6bcGAIv0KjCBbGymQVffWO6YJsmIXYMjLvXHXLotAKGeBEVp
vPnl4Uc8ou/kjY9BNiGX2WAd6FzGPWdUg2KoWe6oWAhHvEu4ZakNYdyxvEMPE3EP
b9iekKH8jd1pivcjV9YBTjQbxOCCQcdwQeZ8wCrFNiXQPbr/gjcJGcThO5Qnv525
ZNepUwdLlJR/kwxDD5c+UyUp82vUiV7uzvilnJztXDG9ZEs5tUJPhfEXqlKtkrAc
lVr67SYai1pO8dUPeiHaN3IDOBEiq74Dxq3lSrFikcPOvq1EBVOdf8TgLxQn4p4S
HQMokfRxkhAeS6JU2PxVOkkbRj/LJsj6RBWbHf9g1SkHxTZbq2+0mptqnRWF7J2t
CLCs847eo+GyKteB6Y9t6JNRW3/WW1i8lE7sdtr/Z7CsOKOrv0H5j7IVPaghCJkL
raqHx18Y66ob/S+wgPRrAgvP5gLyKReJZAj8G6dlypb3ZvCG3XQ=
=vz9E
-----END PGP SIGNATURE-----

--wGv/GnRLoPzJ976+--