From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Xuneng Zhou <xunengzhou@gmail.com>, exclusion@gmail.com,
        pgsql-bugs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>,
        nathandbossart@gmail.com, Melanie Plageman <melanieplageman@gmail.com>,
        Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: BUG #19006: Assert(BufferIsPinned) in BufferGetBlockNumber() is triggered for forwarded buffer
In-reply-to: <CA+hUKG+VjgOp2Tk-JHhbV3F3fpcsFE2g53==Cu55Gv+hP-pabw@mail.gmail.com>
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> <CABPTF7UaVaw6NC9w-y_xexxpP1odHKrqAK4z+H5yg9n9Rrfo7w@mail.gmail.com> <CA+hUKGLRfM423eRyCdf+SKaxEmbbeX-h+tQoc4UY4-UbBZT8dA@mail.gmail.com> <CABPTF7W6gBEh27hU0GVMM8g=GhEhD+nw_oQGS3Lae_h_n03ejA@mail.gmail.com> <CABPTF7WPP2WruqU2zJ1A=E4uuXa4V84WCs+EHRXHNg9BtXXDAA@mail.gmail.com> <CABPTF7Wknc4ZDiphUfAt77=BtgQc47qk0F=tJygstyDCqKSQAg@mail.gmail.com> <CA+hUKG+VjgOp2Tk-JHhbV3F3fpcsFE2g53==Cu55Gv+hP-pabw@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Sat, 11 Apr 2026 13:55:30 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <323815.1775874176.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Apr 2026 22:22:56 -0400
Message-ID: <323816.1775874176@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/323816.1775874176%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> Unfortunately this fell through the cracks (sorry) and I didn't push
> it before the freeze.  Any objections to pushing it now?  I can live
> with deferring it until master reopens if that's the call (CC RMT),
> but it would be nice to tidy up this design wart if we can.

This doesn't seem to me to be a "new feature", so I'm not sure that
feature freeze applies.

> This patch shifts some of that responsibility to a more natural place:

> * it now seems obvious that StartReadBuffers() should just allow an
> in/out npinned counter to travel along with the in/out buffers array
> * read_stream.c still needs to know how many there are for pin limit pur=
poses
> * it also needs to know in the unusual case that the stream ends
> earlier and it has to unpin them
> * other than that, it's StartReadBuffers()'s private business to manage =
them
> * StartReadBuffers() can do that with trivial arithmetic, no need to
> distinguish and count the buffers
> * the end result is much simpler and more robust

IIUC, this is basically fixing StartReadBuffers' API, and if we don't
do it now then the v19 code will differ from both earlier and later
branches.  That doesn't seem like a great place to be when you think
about having to back-patch bug fixes in this area.

So yeah, squeezing this in now seems like a good bet to me.

			regards, tom lane