Re: Out-of-Cycle release? (was Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on MultiXactOffsetSLRU when primary is 16.8)

I had the same problem on 3 different installations Master-Replica with
version 16.11(master) and 16.14(Replica), 14.19(Master) and 14.23(Replica)
and 15.11(Master) and 15.13(Replica).

The issue is happened after patching replica at Operating System with
postgresql package too.

Il giorno gio 25 giu 2026 alle ore 11:30 Michael Banck <mbanck(at)gmx(dot)net> ha
scritto:

> Hi,
>
> moving this to -hackers.
>
> On Wed, May 27, 2026 at 12:06:45PM +0300, Heikki Linnakangas wrote:
> > On 27/05/2026 05:55, Nazneen Jafri wrote:
> > > Tested Andrey's demo.diff on a fresh environment:
> > >
> > > - Primary: REL_16_8, Standby: REL_16_14 (--enable-cassert)
> > >
> > > - ~2300 MultiXacts crossing the offsets page boundary
> > >
> > > - Without patch: startup deadlocks at RecordNewMultiXact(multi=2047)
> > >
> > > - With patch: standby replays all WAL and catches up
> >
> > Thanks all. I have applied this to v14 - v16.
>
> I would like to suggest that this bug-fix might warrant an out-of-cylce
> release (even though it is has been a month since the fix got
> committed). There has been at least one more report on pgsql-bugs[1],
> we (at credativ) have had a customer issue about it and Jan Karremans
> (in CC) mentioned this on Telegram today as well.
>
> To reiterate, this bug is a regression in the latest back-branch
> releases for versions 14-16. If either the standby gets updated to the
> latest minor release first, or if somebody does PITR from a primary on an
> earlier release to an instance with the latest minor release, the
> standby/PITR deadlocks and just sits there.
>
> I think those are pretty important/usual use-cases, so even if versions
> 17/18 are not affected (to-the-best-of-my-knowledge), maybe 14-16 should
> get a re-release for this? Or has this already been discussed among the
> release team?
>
>
> Regards,
>
> Michael
>
>
>