public inbox for [email protected]  

help / color / mirror / Atom feed

From: Sebastiaan Mannem <[email protected]>
To: Andrey Borodin <[email protected]>
To: Michael Banck <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: PostgreSQL mailing lists <[email protected]>
Subject: Re: Out-of-Cycle release? (was Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on  MultiXactOffsetSLRU when primary is 16.8)
Date: Thu, 25 Jun 2026 13:43:32 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAJTYsWU6tdEvVh4YKLxz7+amZ7+Wb7_s-FBjsMMeLNj1fKeSNg@mail.gmail.com>
	<[email protected]>
	<CAJTYsWWXvbBJe+WYJZcnoSTyVz9vk5ro3x2qAq_uvXvK2KwaMQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CA+m5N8s5QGqqxu_re+YFv9PRNrisM7D-Cqbhfj=m8FNZLrovhg@mail.gmail.com>
	<[email protected]>
	<[email protected];lightning.p46.dedyn.io>
	<[email protected]>

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.

view thread (27+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Out-of-Cycle release? (was Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on  MultiXactOffsetSLRU when primary is 16.8)
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox