we now have a customer that has this issue, which is nice, because we might be able to test your fix against their recovery. What we noticed:
* This is a backup recovery scenario (not a standby, but a recovered database backup) * recovery succeeds until a specific WAL file (we call it WAL 86). * Until there we see all WAL apply succeed until a specific record * There we indeed see the next record to be something round a lock We can share the exact lines from pg_waldump, but this seems to be this bug. I will check with the customer if they want to have tested that this bug actually resolves this bug, and let you know. ________________________________ Van: Andrey Borodin <[email protected]> Verzonden: donderdag 25 juni 2026 12:14:46 Aan: Michael Banck CC: Heikki Linnakangas; [email protected]; [email protected]; PostgreSQL mailing lists Onderwerp: Re: Out-of-Cycle release? (was Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on MultiXactOffsetSLRU when primary is 16.8) > On 25 Jun 2026, at 14:30, Michael Banck <[email protected]> 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.
