Feedback-ID: i0fe9450f:Fastmail
Date: Sun, 10 Aug 2025 09:22:10 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Xuneng Zhou <xunengzhou@gmail.com>, exclusion@gmail.com,
	pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: BUG #19006: Assert(BufferIsPinned) in BufferGetBlockNumber() is
 triggered for forwarded buffer
Message-ID: <aJfmMuR0ERs394_c@paquier.xyz>
References: <19006-80fcaaf69000377e@postgresql.org>
 <CABPTF7VaW0Hw2-KXoiYFTH40LeUgr06gE5q09sq9LXQPH-vjPA@mail.gmail.com>
 <CA+hUKGK5x5Yekufz7a+Jr1neahwE9cLZn9xt3gSzSZgE=Spjpw@mail.gmail.com>
 <CA+hUKGJyqwQs_kQFB1J=bx4pHMrMcPF8_PgNKyeNFEo+yNvyiQ@mail.gmail.com>
 <CABPTF7WmR2E+1hAS1ZagBi4c23q6jdRJ8wh1q7XK2Cb2JZYVdw@mail.gmail.com>
 <CA+hUKG+gwez63UpPt1-u2rosh3rW3VeKdve23u-=fi9KWAyz5w@mail.gmail.com>
 <CABPTF7XPmJt9K-HdWRCsUy1EqAh1etMU+WfdOwtML3zXw7OKRQ@mail.gmail.com>
 <CA+hUKGLbAyme3mXVYxp3m5knodZACT8ZXyj2AU+WdtdvEfvVQA@mail.gmail.com>
 <CA+hUKG+cK955=G2gWPcK-yeAx1jz5Ln9_q=x9hMVjU=0zH8=dA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="y4apcFH4bGuM2P3W"
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKG+cK955=G2gWPcK-yeAx1jz5Ln9_q=x9hMVjU=0zH8=dA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aJfmMuR0ERs394_c%40paquier.xyz>
Precedence: bulk


--y4apcFH4bGuM2P3W
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Aug 09, 2025 at 04:03:41PM +1200, Thomas Munro wrote:
> Here is a new version of the slightly more ambitious fix, for
> discussion.  I need to figure out if there is any measurable
> performance impact, but from an interface sanity and fragility POV it
> seems infinitely better like this.  I recall being paranoid about
> function call width, but it still fits in 6 registers.  I think
> perhaps the InvalidBuffer-based API might have seemed a shade more
> reasonable before I reworked the pin limiting logic, but once I had to
> start scanning for forwarded buffers after every StartReadBuffers()
> call, I really should have reconsidered that interface.  In other
> words, maybe a bit of myopic path dependency here...
>
> XXX does the change have any measurable performance impact?
> XXX is the single-buffer specialization unaffected due to dead
> code elimination, as expected?
> xxx unused queue entries could potentially be electrified with
> wipe_mem/VALGRIND_MAKE_MEM_NOACCESS, though existing bufmgr.c assertions
> are very likely to reveal any fencepost bugs already
> XXX perhaps we don't need quite so many _npinned <= _nblocks assertions

With all these comments and b421223172a2 already applied, are you sure
that it is a good idea to play with the v18 branch more than
necessary?  We are in a baked beta2 state, and it looks like all these
could qualify as HEAD-only improvements.

Perhaps the open item can be closed then?
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmiX5jIACgkQnvQgOdby
QH1ESQ//U3JUrpcgp5RNHGJdv1DrnFko0YgPPbK/firYROwlX5BWLfjWqDxtQww3
UUtxKHBBT9u+uKfigkhtD1kbHN62xiDXKJkZVQxnJlMyMx2FA4qtEzb1gGM8f2Zi
nGhdA8N+5Lm13GlouUYWQK6a8NGeLd5MbAgjT/x+LYyrhGMKzNrYxvYIu8tS0yVe
aqAsSp2FoEhVn+0RCyQuGsqkEaTDONqVtIYbSQ2IoojRU2ylEaz15wDoS0388eWV
wnnbTYue5H6IWpIuTyLlPK+vj7Oi9N6C7UDMWpvfH7ByVMo4Qy2V1ilRkXArgrDZ
To3za9w7UpnAXZtXl8rwfWUj13DkmUrjE9azbIhkD/p8wbBMLfzi4Un5AYfrN2c4
5uwrTMr5QFIUYZDFomKKLe874T+i+yIDK/NkOZdEHbCUKEs+/oksSIWO3aKXLfH2
yA2iaMcVL6EX3tTCbKRjEHEyGvb0pZJWj4OyuB8lxT1u6jIB0jm/IKj6ncfZpE5k
RKhpluXPTsndoe7Vo6hAuO6tWZSlpmkrTunxgbd0qAaleca8dJMWldChX9myVmOT
uo20TcVm1JMDBpeqaztRRZjbyNPj+f3NR7LW5Dby9+iaPIgPWhKRqm6IA+12xigh
dVxhX1nUa5DQlw+3Pegsf9fXyw7QHJ9hqdZXmSUBgwagWr8PCUQ=
=FRuq
-----END PGP SIGNATURE-----

--y4apcFH4bGuM2P3W--