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

Michael Banck <mbanck@gmx.net>

From: Michael Banck <mbanck@gmx.net>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, j.karremans@jk-consult.nl, rmt@lists.postgresql.org, PostgreSQL mailing lists <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-25T09:30:32Z
Lists: pgsql-bugs, pgsql-hackers
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



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix self-deadlock when replaying WAL generated by older minor version

  2. Fix multixact backwards-compatibility with CHECKPOINT race condition

  3. Don't reset 'latest_page_number' when replaying multixid truncation

  4. Set next multixid's offset when creating a new multixid