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 1mMYQr-0007EO-Gg for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Sep 2021 16:22:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mMYQq-00053h-7U for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Sep 2021 16:22:16 +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 1mMYQp-00053Y-90 for pgsql-hackers@lists.postgresql.org; Sat, 04 Sep 2021 16:22:15 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mMYQm-00073T-Lc for pgsql-hackers@lists.postgresql.org; Sat, 04 Sep 2021 16:22:14 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8B39C5C00C4; Sat, 4 Sep 2021 12:22:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 04 Sep 2021 12:22:10 -0400 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= fm3; bh=7myOR8+r/lxxZr5OHiVzNzYJFChNyvj4yN3Bm1PWuUs=; b=K/mWtsET ERZZcViHOAlAEucO3SE/0nsdhlFZmtFeHCv/gSw+2ELTqpZNKIrLW337mrqTkBsX BLNM8EkO5GXV4+i5lNY6r6vYihMDqujBbWnCfznv951jWTmfvYbmqZVVcIwcoHoE w9M1uaG6SvubrStGoDbB9EYf+NS46IcrAtwiuAuctjnYbDwfT+thffEB2THr16cu WnHYJMyJiuj4XQKDn0KjqRuyGrLp0AnfTQiKFB+EUff9sWv9hKsnk6N293nXhu4A ZljzuUwflgkAVGEoSjMaZTqwCbTEjUPJvAyid/auJW50Rxl2XaFIvV7xpV2OMp9G wf8Jh2H9V1w1Ig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddvledguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefkeev jedufeeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 4 Sep 2021 12:22:08 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 7FAF22A0811; Sat, 4 Sep 2021 12:22:05 -0400 (-04) Date: Sat, 4 Sep 2021 12:22:05 -0400 From: Alvaro Herrera To: Andres Freund Cc: Kyotaro Horiguchi , masao.fujii@oss.nttdata.com, pgsql-hackers@lists.postgresql.org, bossartn@amazon.com, mengjuan.cmj@alibaba-inc.com, Jakub.Wartak@tomtom.com Subject: Re: prevent immature WAL streaming Message-ID: <202109041622.kq27alud7pir@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210904001423.z5ovkcxugmjwdn2t@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Sep-03, Andres Freund wrote: > Hi, > > On 2021-09-03 20:01:50 -0400, Alvaro Herrera wrote: > > From 6abc5026f92b99d704bff527d1306eb8588635e9 Mon Sep 17 00:00:00 2001 > > From: Alvaro Herrera > > Date: Tue, 31 Aug 2021 20:55:10 -0400 > > Subject: [PATCH v3 1/5] Revert "Avoid creating archive status ".ready" files > > too early" > > > This reverts commit 515e3d84a0b58b58eb30194209d2bc47ed349f5b. > > I'd prefer to see this pushed soon. I've a bunch of patches to xlog.c that > conflict with the prior changes, and rebasing back and forth isn't that much > fun... Done. > > + /* > > + * If we were expecting a continuation record and got an "aborted > > + * partial" flag, that means the continuation record was lost. > > + * Ignore the record we were reading, since we now know it's broken > > + * and lost forever, and restart the read by assuming the address > > + * to read is the location where we found this flag. > > + */ > > + if (pageHeader->xlp_info & XLP_FIRST_IS_ABORTED_PARTIAL) > > + { > > + ResetDecoder(state); > > + RecPtr = targetPagePtr; > > + goto restart; > > + } > > I think we need to add more validation to this path. What I was proposing > earlier is that we add a new special type of record at the start of an > XLP_FIRST_IS_ABORTED_PARTIAL page, which contains a) lsn of the record we're > aborting, b) checksum of the data up to this point. Hmm, a new record type? Yeah, we can do that, and sounds like it would make things simpler too -- I wasn't too happy about adding clutter to AdvanceXLInsertBuffer either, but the alternative I had in mind was that we'd pass the flag to the checkpointer, which seemed quite annoying API wise. But if we add a new record, seems we can write it directly in StartupXLOG and avoid most nastiness. I'm not too sure about the checksum up to this point, though, but I'll spend some time with the idea to see how bad it is. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ Voy a acabar con todos los humanos / con los humanos yo acabaré voy a acabar con todos (bis) / con todos los humanos acabaré ¡acabaré! (Bender)