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 1wch6z-003YFs-2n for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2026 10:15:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wch6x-004qX9-1G for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2026 10:15:07 +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 1wch6w-004qWw-35; Thu, 25 Jun 2026 10:15:07 +0000 Received: from forwardcorp1a.mail.yandex.net ([178.154.239.72]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wch6t-00000000AZ8-0VXv; Thu, 25 Jun 2026 10:15:05 +0000 Received: from mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:bf1f:0:640:c739:0]) by forwardcorp1a.mail.yandex.net (Yandex) with ESMTPS id 9F1DEC0A98; Thu, 25 Jun 2026 13:14:58 +0300 (MSK) Received: from smtpclient.apple (unknown [2a02:6bf:8080:48a::1:1]) by mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net (smtpcorp) with ESMTPSA id uEWKa3BaFqM0-x9gtIV9M; Thu, 25 Jun 2026 13:14:58 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1782382498; bh=nDLOVoYi2LmNonMyzr/aIQplg53jV1UEOTFaactI19Y=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=KJmWTXXPWJXPmSZar5Op4gGAIIS+4IthkLfcSjFLXbeerzGuJ+k20yEfV+HjRN1cS ByrIs9uE8U99WoBw2KmGlPdbyZ6PG2DZDZshrRY5ZPENPkyzQSdkGuaTwiTYZbj3ow ztUmj143OEXmSwA4s5vVr37S2W0TvPSnSfGb2lgM= Authentication-Results: mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) 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) From: Andrey Borodin In-Reply-To: <20260625093032.GA8295@p46.dedyn.io;lightning.p46.dedyn.io> Date: Thu, 25 Jun 2026 15:14:46 +0500 Cc: Heikki Linnakangas , j.karremans@jk-consult.nl, rmt@lists.postgresql.org, PostgreSQL mailing lists Content-Transfer-Encoding: 7bit Message-Id: <50D52121-30FF-4A2D-9230-0EFD953A2C36@yandex-team.ru> 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> To: Michael Banck X-Mailer: Apple Mail (2.3864.600.51.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > 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.