Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wckMp-003arD-0X for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2026 13:43:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wckMo-005z7J-0H for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2026 13:43:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wckMn-005z6u-29 for pgsql-hackers@lists.postgresql.org; Thu, 25 Jun 2026 13:43:41 +0000 Received: from smtpout5.mo537.mail-out.ovh.net ([51.210.91.24]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wckMk-00000000Bz7-1fbV for pgsql-hackers@lists.postgresql.org; Thu, 25 Jun 2026 13:43:40 +0000 Received: from director5.derp.mail-out.ovh.net (director5.derp.mail-out.ovh.net [57.128.106.70]) by mo537.mail-out.ovh.net (Postfix) with ESMTPS id 4gmKl942Lxz3xhc; Thu, 25 Jun 2026 13:43:33 +0000 (UTC) Received: from director5.derp.mail-out.ovh.net (director5.derp.mail-out.ovh.net. [127.0.0.1]) by director5.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Thu, 25 Jun 2026 13:43:33 +0000 (UTC) Received: from pro1.mail.ovh.net (unknown [10.110.37.126]) by director5.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4gmKl91nhnz7tLj; Thu, 25 Jun 2026 13:43:33 +0000 (UTC) Received: from DAG25EX2.emp.local (172.16.2.252) by DAG25EX2.emp.local (172.16.2.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Thu, 25 Jun 2026 15:43:32 +0200 Received: from DAG25EX2.emp.local ([fe80::42d0:da65:665d:336b]) by DAG25EX2.emp.local ([fe80::42d0:da65:665d:336b%8]) with mapi id 15.02.2562.043; Thu, 25 Jun 2026 15:43:32 +0200 From: Sebastiaan Mannem To: Andrey Borodin , Michael Banck CC: Heikki Linnakangas , "j.karremans@jk-consult.nl" , "rmt@lists.postgresql.org" , PostgreSQL mailing lists 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) Thread-Topic: Out-of-Cycle release? (was Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on MultiXactOffsetSLRU when primary is 16.8) Thread-Index: AQHdBIty2FtS1M6JDkWCr9L4iSCEVbZPR9vE Date: Thu, 25 Jun 2026 13:43:32 +0000 Message-ID: References: <9DF05C0C-D165-4821-80C2-FFAF47C07FF4@yandex-team.ru> <90F2A05B-FEEB-4695-87ED-32F53C6AC097@yandex-team.ru> <4016ab8b-84c0-4606-8a77-67ad5b157bfc@iki.fi> <20260625093032.GA8295@p46.dedyn.io;lightning.p46.dedyn.io>,<50D52121-30FF-4A2D-9230-0EFD953A2C36@yandex-team.ru> In-Reply-To: <50D52121-30FF-4A2D-9230-0EFD953A2C36@yandex-team.ru> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.81.225.122] Content-Type: multipart/alternative; boundary="_000_a872b7702bb14d349ad61a769afc6897mannemnl_" MIME-Version: 1.0 x-ovh-tracer-id: 3496200688950927881 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: dmFkZTG3bhQEfIj+44d5Ls3Gv1xjV5p67kjVF0ibo2Luzo18qTrCm/chTNRPkkBPZDCdUdP1bwRlLAR407f+b+oVUErvqyCpE2ve4KdAYZFj7LXM/9x6ZSu+UIq5PXn0oHZ/l6yH+x02CQOYrHBEvQ8Y7iAIV7Fh5GC7k0wZkOwTwRxOzABhB+VG1pfFl/rEog4ohX91r0+Ss0pb+xptRpOAYqpnx0GkcZgpHdGdPsJf/Wl+DjB+RuT78/DWv0HBQYiCD2z7WEF4nk1vBCEICZzyDRSE82xE0RjXNdy98fgPXGXpvKVR/xPU9kE41JCjm1TTVcf1lODSkKaumMc3Lt9KH1kDlCxaoQajzL6TeF0LHbdgQvHQG4TGGQqjrZOSqjrhwlQcXXbqOAaNRXYdwkwUD2XXP98g7jhA6VIAxrGQ0BlJzNz4hPDHTJ6uHHz+IvXA1nYyykH1zAKa+uufhfhG3utN4/Y7wYOkY0jlcGxhj2eBHhRNRdeLeoe4rPmqMUnqjAglXQa8BwY7yniUrfUx2X7SQCQlfyRAtHUOsdg2qdBuwlnWXEJlsoWfE0rvaRzCocQ+T8dvq0V79R2L8Nqonf6fzRk0bf97b5G31oD3R78Ym//23mQbRVTei8Nbyn5PmnkZU1657G9IeZX4gCrZ3W2d+oLzzCulmdgIaWKosdfdTA List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_a872b7702bb14d349ad61a769afc6897mannemnl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 da= tabase 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 ac= tually resolves this bug, and let you know. ________________________________ Van: Andrey Borodin Verzonden: donderdag 25 juni 2026 12:14:46 Aan: Michael Banck CC: Heikki Linnakangas; j.karremans@jk-consult.nl; rmt@lists.postgresql.org= ; 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 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. --_000_a872b7702bb14d349ad61a769afc6897mannemnl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

we now have a customer that has this issue, which is nice, because w= e might be able to test your fix against their recovery.
What we noticed:

  • This is a backup recovery scenario (not a standby, but a rec= overed database backup)
  • recovery succee= ds 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 ac= tually resolves this bug, and let you know.

Van: Andrey Borodin <x= 4mmm@yandex-team.ru>
Verzonden: donderdag 25 juni 2026 12:14:46
Aan: Michael Banck
CC: Heikki Linnakangas; j.karremans@jk-consult.nl; rmt@lists.postgre= sql.org; 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 <mbanck@gmx.net> wrote:<= br> >
> 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<= br> 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.




 --_000_a872b7702bb14d349ad61a769afc6897mannemnl_--