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 1mG7d8-00012b-Am for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Aug 2021 22:32: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 1mG7d7-0006EQ-8t for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Aug 2021 22:32:21 +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 1mG7d6-0006E7-9T for pgsql-hackers@lists.postgresql.org; Tue, 17 Aug 2021 22:32:21 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG7d3-0000hL-QI for pgsql-hackers@postgresql.org; Tue, 17 Aug 2021 22:32:19 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0DD0C3200958; Tue, 17 Aug 2021 18:32:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 17 Aug 2021 18:32:15 -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=8coyNo14oTQO+jmcXbOjeKESOMMoWXBLHZevMi1m0ZY=; b=bP7GW8lZ CKbuBS88MWmmhk2RX5+DZR5tFK5fIPCuGftSvyOze+lkxSeAFs5a2GxnyZ4kgeQY labYnDMpsIwzD38Rl+l8ARf1aEcNuIxeZQXYSm7HMkN8RDmpjU2dqK/GMB5xf2PB IfYppb8KckMfI5buXtIUngg/MCvKMWF5L2Gamy15FbGQnr0yi0KJGrT1z4xLb208 ABbX1YX+fSjfAx67nTNDztAv9GNLd5oa8FOpfdnduy8wgubYuJoTU9R5kzDITbXc lokz4KRDlpcxpuC07ZBjVQNsJ2Cp3t0WM3q57wJNAmxWmhc/Zn56LZgeNRBn2UOj RqUVArFJIoZ9IA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleeggddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomhepfdgrlhhvhhgv rhhrvgesrghlvhhhrdhnohdqihhprdhorhhgfdcuoegrlhhvhhgvrhhrvgesrghlvhhhrd hnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpefhudeftdfhleevgeejtdffudel keeiudfgtdfgtddtveetjeelteeghfeuiefgteenucffohhmrghinhepvghnthgvrhhprh hishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Aug 2021 18:32:11 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id A0B152A099B; Tue, 17 Aug 2021 18:32:08 -0400 (-04) Date: Tue, 17 Aug 2021 18:32:08 -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: <202108172232.nqewuhgxhxty@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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/17/21, 2:13 PM, "alvherre@alvh.no-ip.org" wrote: > > > So, why isn't it that we call Register in XLogInsertRecord, and > > Notify in XLogWrite? > > We do. However, we also call NotifySegmentsReadyForArchive() in > XLogInsertRecord() to handle the probably-unlikely scenario that the > flush pointer has already advanced past the to-be-registered boundary. > This ensures that the .ready files are created as soon as possible. I see. I have two thoughts on that. First, why not do it outside the block that tests for crossing a segment boundary? If that's a good thing to do, then we should do it always. However, why do it in a WAL-producing client-connected backend? It strikes me as a bad thing to do, because you are possibly causing delays for client-connected backends. I suggest that we should give this task to the WAL writer process -- say, have XLogBackgroundFlush do it. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "All rings of power are equal, But some rings of power are more equal than others." (George Orwell's The Lord of the Rings)