Horton
Menu

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

Andrey Borodin <x4mmm@yandex-team.ru>

View thread
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Michael Banck <mbanck@gmx.net>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, j.karremans@jk-consult.nl, rmt@lists.postgresql.org, PostgreSQL mailing lists <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-25T10:14:46Z
Lists: pgsql-bugs, pgsql-hackers 

> On 25 Jun 2026, at 14:30, Michael Banck <mbanck@gmx.net> wrote:
> 
> 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.

A bit of clarification. To trigger this bug WAL must be generated by 16.10
or prior and replay must be done by latest release (16.14). And the WAL
trace must contain sufficient number of MultiXacts.

So far we had 3 or 4 reports on pgsql-bugs and few in chats.

But yeah, restoration from an old backup is a typical use case.


Best regards, Andrey Borodin.

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