Date: Fri, 25 Dec 2020 10:51:00 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org
Subject: Re: Large objects and out-of-memory
Message-ID: <X+VFhCg3dFJvsyX2@paquier.xyz>
References: <7c57860c-fc05-143e-aa81-f11ca13ec00a@postgrespro.ru>
 <543675.1608575245@sss.pgh.pa.us>
 <8044c223-4d3a-2cdb-42bf-29940840ce94@postgrespro.ru>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="AsGhKi797xIiwjG5"
Content-Disposition: inline
In-Reply-To: <8044c223-4d3a-2cdb-42bf-29940840ce94@postgrespro.ru>
Precedence: bulk


--AsGhKi797xIiwjG5
Content-Type: multipart/mixed; boundary="kbzH979j2fmPgWKU"
Content-Disposition: inline


--kbzH979j2fmPgWKU
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 24, 2020 at 05:06:34PM +0300, Konstantin Knizhnik wrote:
> Also I noticed small inconsistency in inval.c:
>=20
> =A0=A0=A0 else if (msg->id =3D=3D SHAREDINVALSNAPSHOT_ID)
> =A0=A0=A0 {
> =A0=A0=A0 =A0=A0=A0 /* We only care about our own database and shared cat=
alogs */
> =A0=A0=A0 =A0=A0=A0 if (msg->rm.dbId =3D=3D InvalidOid)
> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 InvalidateCatalogSnapshot();
> =A0=A0=A0 =A0=A0=A0 else if (msg->rm.dbId =3D=3D MyDatabaseId)
> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 InvalidateCatalogSnapshot();
> =A0=A0=A0 }
>=20
> Here we are processing snapshot invalidation message but using structure =
for
> relation map invalidation.
> It doesn't cause problems because only dbId field is used and it has the
> same offset
> in SharedInvalRelmapMsg and SharedInvalSnapshotMsg structures.
> But it should be fixed.

Good catch.  It is very easy to miss that this is not "rm", but "sn".
I have checked the rest of this area and did not notice similar
errors.  I'll backpatch the attached if there are no objections.  This
may look cosmetic, but this would cause unnecessary conflicts if this
area gets touched and it would be hard to miss.  This comes from
568d413.  There may be a point in having a single call to
InvalidateCatalogSnapshot() as well..
--
Michael

--kbzH979j2fmPgWKU
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="inval-inconsistent.patch"

diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 628d6f5d0c..e7279d06a3 100644
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -622,9 +622,9 @@ LocalExecuteInvalidationMessage(SharedInvalidationMessage *msg)
 	else if (msg->id == SHAREDINVALSNAPSHOT_ID)
 	{
 		/* We only care about our own database and shared catalogs */
-		if (msg->rm.dbId == InvalidOid)
+		if (msg->sn.dbId == InvalidOid)
 			InvalidateCatalogSnapshot();
-		else if (msg->rm.dbId == MyDatabaseId)
+		else if (msg->sn.dbId == MyDatabaseId)
 			InvalidateCatalogSnapshot();
 	}
 	else

--kbzH979j2fmPgWKU--

--AsGhKi797xIiwjG5
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl/lRYQACgkQnvQgOdby
QH1Mdw//YJq2NuXSVt3gFB/vbrXkRF/jV/eIeMuCgxMTTLfFzBSKWk/iDbABRsaI
TcqfIgZmPE5DH3jUGFEZ7jZMaxiuq7wWPaPHRi3oHyS80Zp5MoETP4rCssmcGTp6
NqWFy45ToT2YQ/67S90a5xIQJXBNwGETO7KYzpjER81r7GfPzOuhCt4H/I7Hxio7
GxH05RxPcf719NNHY5bB2Wax3CEgtoov7AjHZkrZlicxdS18zDpbQLsbTAtnneSw
wvPaSlbPUvS2yZqPvTLl9Q+xRo64+vMSFsuB1LQlaFwR5CgM2Il3gB7QopWQHKmU
rvnIq6AWVnJZmRRo6S73YhSGJtxM4AEHThwBYDx13PPNZwxMhpIashJ6sZPKit1b
hSSwM2N6SRuIJfhF1Tv/LfAsIpcr3UgiBXba2w5t6XHQZJjr+nSa1kvvBomTocRc
l9hCa3eFNzovpDwtWg0oXUlNZ51mOo/9AZfI8y7GwL7hlvLTqnVqozWrc7Jz4ud9
cZ1pDKuYu73nfF4nPZVJ+qmeiQdfV/vvn1hQn+xBYmBkLXri/1arfH+j8YaKdF85
yBVos1LAfjGSk4zVf87xOnt9zNgsoZwwO73k4EzzdQVt7/v1xsGNGSOcyKnoHNop
JvvQPCkUw/7NwwRf21gKtc5F7ld6You02z4ezFRYdR329toaHOQ=
=df9N
-----END PGP SIGNATURE-----

--AsGhKi797xIiwjG5--