Re: BUG: ReadStream look-ahead exhausts local buffers when effective_io_concurrency>=64

On Wed, Aug 5, 2026 at 11:51 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> On Thu, Jul 23, 2026 at 11:07 AM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> >
> > On Thu, Jul 2, 2026 at 7:50 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > >
> > > If that's the case, I'm wondering whether it makes sense to backpatch
> > > this fix to 18. I tried to do this for the local tree and the
> > > reproducer passed. That said, it might not be safe to do so for a
> > > stable version. It would be helpful to hear Melanie's and Andres's
> > > thoughts on this.
> >
> > da6874635db fixes the originally reported bug in this thread on 18. It
> > makes sense to backpatch it to 18. I hadn't thought of the TOAST case.
> > I'm thinking about whether backpatching to 17 makes sense or not. It
> > would be much more difficult to hit an issue in 17, but I'll need to
> > think more about it.
>
> I've backpatched the fix to pg 18. After some analysis, it seems we
> can not hit the issue with any non-contrived example in 17 because in
> practice sequential scans won't bump the lookahead distance past
> io_combine_limit which can't exceed the minimum temp_buffers value.
> There may be some contrived way to hit it with analyze but it seems
> far-fetched. Also on 17, it's not a clean cherry-pick because we don't
> have GetAdditionalLocalPinLimit(), and there seem to be more
> implications to changing LimitAdditionalLocalPins(). So, for now,
> let's just patch 18.

Thanks for dealing with it. The backpatching decision also makes sense to me.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.