Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mqKtE-0007Ka-6o for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Nov 2021 19:58:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mqKtB-0007Hd-U2 for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Nov 2021 19:58:37 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mqKtB-0007H4-0D for pgsql-hackers@lists.postgresql.org; Thu, 25 Nov 2021 19:58:37 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mqKt7-0004Kj-UM for pgsql-hackers@lists.postgresql.org; Thu, 25 Nov 2021 19:58:35 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 5841A580663; Thu, 25 Nov 2021 14:58:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 25 Nov 2021 14:58:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=9FOIqTaqsJabP02vj+jMIDS6+B65EpT7n7mFqoaLIGQ=; b=BSLep/dl L9Ac/LhaYWsg7hU7fB3m79YrSz23bObXViFcgNTeHBBZ9qs2zA+ukuOoJv2+U6DA 9S1fYKj6wlEFsBFXw8dkHfc5eBbaC/73mMNZjPGHBWzi7/qK+c3fJ/zJGwpzp3sW SNIug2aszOKxLzknXxYNfGhGoDFC5iDoYzNMldMbVwURripToL9cb8LhYp/f9v5w vJKw76hYwF18wPSgvEhDNbtgEQMM9Q3U4ZfI7dn+3RoxTLZoZaVgLuaLgDfh+/jb zUp0U/Z3NCmqqXHbDEBpmHpLvdzpVcv9sU8PfoZkzaQ1oDa00w0f9qQ6ces9+6vo ZiYjb2xa7LvzMA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrhedtgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehmkeerredttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeetvdfhteeuueekfefhfedugeffhfehhfdvleffleetkeeg geefhffggeekjedtudenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Nov 2021 14:58:30 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 655912A07F5; Thu, 25 Nov 2021 16:58:28 -0300 (-03) Date: Thu, 25 Nov 2021 16:58:28 -0300 From: Alvaro Herrera To: Tom Lane Cc: Amul Sul , Andres Freund , Andrew Dunstan , "Bossart, Nathan" , Kyotaro Horiguchi , "masao.fujii@oss.nttdata.com" , "pgsql-hackers@lists.postgresql.org" , "mengjuan.cmj@alibaba-inc.com" , "Jakub.Wartak@tomtom.com" , Ryo Matsumura Subject: Re: prevent immature WAL streaming Message-ID: <202111251958.z7xaqbby632w@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zwyauspwcig5eb3y" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <313645.1637867900@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --zwyauspwcig5eb3y Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2021-Nov-25, Tom Lane wrote: > Alvaro Herrera writes: > > > The problem is that the bug occurs while writing the WAL record. Fixed > > servers won't produce such records, but if you run an unpatched server > > and it happens to write one, without a mitigation you cannot get away > > from FATAL during replay. > > Really? AFAICS the WAL record contains the correct value, or at least > we should define that one as being correct, for precisely this reason. I don't know what is the correct value for a record that comes exactly after the page header. But here's a patch that fixes the problem; and if a standby replays WAL written by an unpatched primary, it will be able to read past instead of dying of FATAL. I originally wrote this to have a WARNING in VerifyOverwriteContrecord (in the cases that are new), with the idea that it'd prompt people to upgrade, but that's probably a waste of time. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens) --zwyauspwcig5eb3y Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="0001-Fix-LSN-in-OVERWRITTEN_CONTRECORD.patch" From c28d96dfeb0884dff58b989fc0b869ee0f7806e5 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Thu, 25 Nov 2021 16:19:42 -0300 Subject: [PATCH] Fix LSN in OVERWRITTEN_CONTRECORD If the record that was broken starts exactly at a page boundary, we write the byte position at which the record data appears (skipping the WAL page header), which isn't the actual LSN of the record. Repair. To avoid problems on production systems which might use the bogus code, change the test so that LSNs at page boundaries are also considered equal to the byte position for the record data. This means that if an unpatched server produces a bogus OVERWRITTEN_CONTRECORD, WAL replay can continue after upgrading to a server containing this patch. --- src/backend/access/transam/xlog.c | 9 ++++++++- src/backend/access/transam/xlogreader.c | 2 +- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 5a8851a602..1f1ae23526 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -10706,7 +10706,14 @@ xlog_redo(XLogReaderState *record) static void VerifyOverwriteContrecord(xl_overwrite_contrecord *xlrec, XLogReaderState *state) { - if (xlrec->overwritten_lsn != state->overwrittenRecPtr) + /* + * 14.1 and sibling server versions wrote XLOG_OVERWRITE_CONTRECORD with a + * bogus recptr. See https://postgr.es/m/45597.1637694259@sss.pgh.pa.us for + * details. + */ + if (xlrec->overwritten_lsn != state->overwrittenRecPtr && + xlrec->overwritten_lsn - SizeOfXLogShortPHD != state->overwrittenRecPtr && + xlrec->overwritten_lsn - SizeOfXLogLongPHD != state->overwrittenRecPtr) elog(FATAL, "mismatching overwritten LSN %X/%X -> %X/%X", LSN_FORMAT_ARGS(xlrec->overwritten_lsn), LSN_FORMAT_ARGS(state->overwrittenRecPtr)); diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c index f39f8044a9..4772cd1664 100644 --- a/src/backend/access/transam/xlogreader.c +++ b/src/backend/access/transam/xlogreader.c @@ -586,7 +586,7 @@ err: * in turn signal downstream WAL consumers that the broken WAL record * is to be ignored. */ - state->abortedRecPtr = RecPtr; + state->abortedRecPtr = state->currRecPtr; state->missingContrecPtr = targetPagePtr; } -- 2.30.2 --zwyauspwcig5eb3y--