Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wX9o8-0035wf-2f for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 03:40:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wX9o7-008z4c-2R for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 03:40:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wX9o7-008z4U-0A for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 03:40:47 +0000 Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wX9o4-00000001wpL-443l for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 03:40:46 +0000 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 7D8EB140010C; Tue, 9 Jun 2026 23:40:43 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Tue, 09 Jun 2026 23:40:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1781062843; x=1781149243; bh=Co1trymGwV zRlh8nXOkB2Gmfzbb+irzvZkb1wT33Uio=; b=Zf1ywsdCq9k2RB35gpAWLKorIh sU8FT6zAyUTlqBCCMBCXa5G3mCKp4FBUzGDtgRvhUf8IxrvmeBfhYV6gYfI/VKqh 8QzXsdP/qBL+0hOc8XBO4nvvxIxjokCihZ4ctLOdNrfoi/Xh2i9U3OWkAnGepw+y R/kc51ZPZ3medKxeeLk0ajDhZ5n1bvfGK51Z2gs5ctDhy0nOZbp5YMq+Qt9YQYEN NHS7LXi2HrduWjaaJ5pXWZMYyCN0+EetUL2lVlDOa6/AR6BLTdMg0NWcZ1tm3/YB BkxrnAtjVhYDFCQnNCGbEgHc/OytxmPbTFVAEmoKInUBBAgtdfLeHkg3lr9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1781062843; x=1781149243; bh=Co1trymGwVzRlh8nXOkB2Gmfzbb+irzvZkb 1wT33Uio=; b=Oeb/6Wyr4bTQ0QQ5U0H/Hg5+K/uCc4XB4gG2VsaYVjQQTJ0A7Au PirL7jcE24sXZN5H6UY9SZpfBbJmvzsfDJatFBTDeM8B7e/seS0sgDNV2d/dvSA2 Zms0/KQ76xxqfmMXQupj1csfaw6tOWI4gHRkYOBMWOUQXOS3T3UneqC8KrZYS2P9 4CYBdxoULM8G3UYDqweJWTF7OjXdqnrx9fiFqHHBg9GLX6zUvUwrH2ASjBUY+Q2X YWWQm9hb5S8OnxDllFQ7cZ2hpE4f2tdUI/84cSb6HZte3tQSNaczh2ySAHMbcrYI UKgi1fDgeiuBb5FF9P7xUNmzoK2z9ZwefFQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFM40XHP5r7KPSIb2EBpgbRsErM8DIAmYEv5o5bG8KKvuhk3KJxIFVafke20fhWSy A7BK51f0hvqOmr3lSojhePeFNSL56f2zbwkfuVJ1r04Tz/3ojppRSmdzK1qwWWfn8x7Wbs gICp24lAVTXDsjaHxRy9q2X8NxU448Jgx27j9uE8Jo1TTEhTBB6Ymxty4mL7ggeS6ipKC6 1hVzbuNLnDJdbycZrCdoc5fCCqNAYvKxmLCHenoNlDnBgTnQcOc0GKhKaVL5S8TKjkveoH B1GyTbPRUrYh8yFVGGAi88ntuayoshSGsMQ7wReBs4W9EpEap0EzOgVDIVWhOVF8zzwCgC 23uD4cRfYt7sTj7Ksz5GYIdLoixAp8o4qxy97zED9ZoR3g/rFWJUESx3xWRoohlvaXLTcz wFFSiLeTg/Bz+gT+GxRvt/IH9UBRwbMyGC0CUrNOO/E+RirwVNXuqa/MVyP4r5N/HBhfdb fWu8Y4JkKXDxasguIno5QjStT4Rpc3j3/rDV8/jh2xRMxejfoGN1SxKL90fDtTzSgEq5Zc +0kxe1Kar2GU4dRKvw5wtb8Jn9odJbukPQe623mTzpZ0otZkeA/C3V0yc8xtqumsSazkyy 8ty1cc1brJSp13ExBvYSwWU8bNIY7avILmlT7t1ovAJwVyieQnKsakQyA96w X-ME-Proxy: Feedback-ID: i0fe9450f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 9 Jun 2026 23:40:42 -0400 (EDT) Date: Wed, 10 Jun 2026 12:40:38 +0900 From: Michael Paquier To: Ashutosh Bapat Cc: Andres Freund , PostgreSQL Hackers Subject: Re: GetBufferDescriptor() being called for local buffers from MarkBufferDirtyHint() Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hwjAYTziNE03xjjA" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --hwjAYTziNE03xjjA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 06, 2026 at 01:37:42PM +0530, Ashutosh Bapat wrote: > 82467f627bd478569de04f4a3f1993098e80c812 added MarkBufferDirtyHint() > which invokes GetBufferDescriptor() even for local buffers for which > id < 0. Since GetBufferDescriptor() declares id as uint32, -1 is > converted to a very large int32 value which is way larger than > NBuffers. Thus GetBufferDescriptor() may be returning something from > the BufferBlocks which probably has enough memory to accommodate that > memory access. But it's a bogus BufferDesc nevertheless. We are not > seeing any problem with this right now since MarkBufferDirtyHint() > uses the BufferDesc only when it's a shared buffer. Right fix is to > let that function handle local buffers first and then call > GetBufferDescriptor() as in the attached patch. @@ -5831,8 +5831,6 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std) { BufferDesc *bufHdr; =20 - bufHdr =3D GetBufferDescriptor(buffer - 1); - if (!BufferIsValid(buffer)) elog(ERROR, "bad buffer ID: %d", buffer); =20 @@ -5842,6 +5840,8 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std) return; } =20 + bufHdr =3D GetBufferDescriptor(buffer - 1); Yep, that's clearly wrong. We are lucky that it does not blow up today but that's a ticking bomb. Even with that in mind, the result leads to a non-defined behavior. - return &(BufferDescriptors[id]).bufferdesc; + BufferDesc *bdesc =3D &(BufferDescriptors[id]).bufferdesc; + + Assert(bdesc->buf_id =3D=3D id); + + return bdesc;=20 [...] - BufferDesc *buf =3D GetBufferDescriptor(i); + /* GetBufferDescriptor() expects buf_id to be set in the descripto= r. */ + BufferDesc *buf =3D &(BufferDescriptors[i]).bufferdesc; I am not convinced by these two. For the first one, the assertion is a bound check in disguise, which could also use NBuffers as of an (id < NBuffers). With the inlining we care about the performance. This also forces the second change in ShmemInit(), which makes even less sense once we think about the first assertion. Will fix the first issue on HEAD, that's wrong. Thanks for the report. -- Michael --hwjAYTziNE03xjjA Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmoo3LYACgkQnvQgOdby QH0KWQ/+IpiLKR8fEjizkMF5sEbtpWNki2dIpH1DMqdAJOCGPnjEblsK0tK2VIVc OoJMqw6hjLPeY0eUNX2gbq6d/KHE1UIdx0e86Alz/usG5/c9PAxBOWHgUehLecfp j2qn+53ejA9eoBXJTEvfkfOCXfgrcl4NU8TVNmCN9qs0JxQPGporUD2XVreW7S7w Msg72X+deigUL0G1dKPF1084rkqg7aJqbpq9CBuPYic3bY+Liru+yQj6rx8Rixdd 8TL/aqhm/ts0k+6iHe/8e72y/ruUBeq0YXqVjNJSmJ+5TCi5+jU49c+EsdDgqLgd d1ydbYEWAF8h8W+jNudYGoEw4hPbsX9KoV2/IKD2nggBjkSsLy//v23VgYSNDfgw hp8eOvG++1Ij35DLIVfIEmhIiAVLcBWLxyZAH9DiZNO1W++S5wiI4Rmoy1u/2gJJ L7QKWxRVWhpTE6KLd4gSMY4FjUQHfKAEDDj3QPmbJl7NoldXjZ3tHKnves7FB6qj XTaFN/iB59KLUMOkk/kDK4ruSKa67uyPStumBGfAoUYVC84KeP9FmhxvtyJnC+7E jkhe5SZKE8NK6BP68lPdsAyZYbE4QMat2j7bGnDKoaZTwQ3BuziD1vf0Z0QVppS2 8cAgC0aJnwbHRI47ZYnnVQOjEXbek2GConjaUVAfIUXJqFm8qD0= =wOYl -----END PGP SIGNATURE----- --hwjAYTziNE03xjjA--