MIME-Version: 1.0
References: <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>
 <323816.1775874176@sss.pgh.pa.us> <ad0mtIJhfwiGkxCD@paquier.xyz>
In-Reply-To: <ad0mtIJhfwiGkxCD@paquier.xyz>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Wed, 15 Apr 2026 09:30:05 +0800
Message-ID: <CABPTF7WQRGqnhCvcE0fNSzCS9R22ArWdsVNH4RDWCso9zV-s_Q@mail.gmail.com>
Subject: Re: BUG #19006: Assert(BufferIsPinned) in BufferGetBlockNumber() is
 triggered for forwarded buffer
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, exclusion@gmail.com, 
	pgsql-bugs@lists.postgresql.org, nathandbossart@gmail.com, 
	Melanie Plageman <melanieplageman@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CABPTF7WQRGqnhCvcE0fNSzCS9R22ArWdsVNH4RDWCso9zV-s_Q%40mail.gmail.com>
Precedence: bulk

On Tue, Apr 14, 2026 at 1:24=E2=80=AFAM Michael Paquier <michael@paquier.xy=
z> wrote:
>
> On Fri, Apr 10, 2026 at 10:22:56PM -0400, Tom Lane wrote:
> > 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.
>
> I have read the patch and I would agree this stance.
>
> >> * 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 p=
urposes
> >> * 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 manag=
e 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.
>
> +1 for doing it now.  It's also worth noting that this shaves code
> line-wise.

+1.


--
Best,
Xuneng