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 1mG38Q-0002gu-BJ for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Aug 2021 17:44:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mG38O-0006ly-E8 for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Aug 2021 17:44:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG38O-0006lq-67 for pgsql-hackers@lists.postgresql.org; Tue, 17 Aug 2021 17:44:20 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG38H-0005KK-0R for pgsql-hackers@postgresql.org; Tue, 17 Aug 2021 17:44:19 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3F0615C0172; Tue, 17 Aug 2021 13:44:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 17 Aug 2021 13:44:11 -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=Px+DXdQzmtfjvYwwkDDhnI5kl6/m4ShS2nkJrS5P+rU=; b=fULGIiXY ecTn7Huk7wC2d1C7tzLihcl1jAqGrepyBWWaRuWUj75vMB9Ajwb4+6sCZYrwbSM5 FjMBovXqHI4M+bVx3INPdoifcvpZAbaupXX9hdfTVp1mWwOIPYsXTFrkGPHWZYd0 WBkT4Zn44yA0hSTSq/KKxgre2OwrwDuGrZ6AOVMAEbyLRj8ZXm9tZSzxDfrMuQbW xmpiIp3TVxMb+aj/NsKCGgELj3V/1j+4w66s5L5JMun779X9O1ORzFr7oEvlB6Ym /m75QoJ6v1YtFvbLH7oguw3NfaBuP3bNWMlcqOzyhh7VS2WkK9EHJwaL4o5MX4CU +FrPvFFhoTxVjQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleefgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpedfrghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrghdfuceorghlvhhhvghrrhgvsegrlhhvhh drnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhephfdufedthfelveegjedtffdu leekiedugfdtgfdttdevteejleetgefhueeigfetnecuffhomhgrihhnpegvnhhtvghrph hrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Aug 2021 13:44:08 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 7F1C72A099B; Tue, 17 Aug 2021 13:44:05 -0400 (-04) Date: Tue, 17 Aug 2021 13:44:05 -0400 From: "alvherre@alvh.no-ip.org" To: "Bossart, Nathan" Cc: Kyotaro Horiguchi , "x4mmm@yandex-team.ru" , "a.lubennikova@postgrespro.ru" , "hlinnaka@iki.fi" , "matsumura.ryo@fujitsu.com" , "masao.fujii@gmail.com" , "pgsql-hackers@postgresql.org" Subject: Re: archive status ".ready" files may be created too early Message-ID: <202108171744.wzeymligc6e2@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1264128B-5757-4A56-974E-45447FC09433@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Aug-17, Bossart, Nathan wrote: > On 8/16/21, 5:09 PM, "alvherre@alvh.no-ip.org" wrote: > > The reason for the latter is that I suspect the segment boundary map > > will also have a use to fix the streaming replication issue I mentioned > > earlier in the thread. This also makes me think that we'll want the wal > > record *start* address to be in the hash table too, not just its *end* > > address. So we'll use the start-1 as position to send, rather than the > > end-of-segment when GetFlushRecPtr() returns that. > > I've been thinking about the next steps for this one, too. ISTM we'll > need to basically assume that the flush pointer jumps along record > boundaries except for the cross-segment records. I don't know if that > is the safest assumption, but I think the alternative involves > recording every record boundary in the map. I'm not sure I understand your idea correctly. Perhaps another solution is to assume that the flush pointer jumps along record boundaries *including* for cross-segment records. The problem stems precisely from the fact that we set the flush pointer at segment boundaries, even when they aren't record boundary. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth)