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 1mGQKR-0002tS-2o for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Aug 2021 18:30:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mGQKP-0001zF-WA for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Aug 2021 18:30:18 +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 1mGQKP-0001z7-OO for pgsql-hackers@lists.postgresql.org; Wed, 18 Aug 2021 18:30:17 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mGQKN-0000oX-2e for pgsql-hackers@postgresql.org; Wed, 18 Aug 2021 18:30:17 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 3626B320093F; Wed, 18 Aug 2021 14:30:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 18 Aug 2021 14:30:12 -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=3O9D5UKDakF4ZCjmzuwpW/9ggUF5dO1nf7Z9pV9R28Y=; b=Wl7RZBxu pYbtKvyj6pl/aIwbFa7L1h1TrO/w+xsEiMZZgDAbmzhg/g7g7pu+DpXKMx/KCEL+ cxW1gz5k6LynAF52zc6DV1Q1vxezIq1cktgTBgTojk/FP+6fSjBuNsrmXDjAiaT3 9jbDx33uyTtci5gwOTGhdbK4r8LZWHbm82cOXGlcEnsUaFZwGXLpcHbECri6AYbi TdWpUz4gNITvmTUuemHiR2sRAPo9zkxxwPYlEKv5QeSv1gOM//Ve8lu7ok9ujI4m FO6FauhvpWDyGeDujkHQCnpksW5AAO9sNtk7wG+3BfHFEX3/CWghRGbVkO61gxVp un5wJDdzrvRo3g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleehgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpedfrghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrghdfuceorghlvhhhvghrrhgvsegrlhhvhh drnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhephfdufedthfelveegjedtffdu leekiedugfdtgfdttdevteejleetgefhueeigfetnecuffhomhgrihhnpegvnhhtvghrph hrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Aug 2021 14:30:08 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C3E6F2A093F; Wed, 18 Aug 2021 14:30:05 -0400 (-04) Date: Wed, 18 Aug 2021 14:30: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: <202108181830.wgxahkv2eu3y@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-18, Bossart, Nathan wrote: > I'll add it after XLogBackgroundFlush(). I was wondering which would be better: before or after. XLogBackgroundFlush would do it anyway, so if you do it after then it's not clear to me that it'd do anything (I mean we should not do any new calls of NotifySegmentsReadyForArchive and just rely on the one in XLogBackgroundFlush -> XLogWrite). The advantage of doing NotifySegmentsReadyForArchive before XLogBackgroundFlush is that the files would be created sooner, so the archiver can be working in parallel while walwriter does its other thing; then we'd reach the NotifySegmentsReadyForArchive in XLogBackgroundFlush and it'd find nothing to do most of the time, which is just fine. > I think we'll also want to set the WAL writer's latch in case it is > hibernating. Yeah. (That's another advantage of doing it in walwriter rather than bgwriter: we don't publish bgwriter's latch anywhere AFAICS). > Another approach could be to keep the NotifySegmentsReadyForArchive() > call in XLogInsertRecord(), but only call it if the flush pointer is > beyond the boundary we just registered. Or we could only set the > latch in XLogInsertRecord() if we detect that the flush pointer has > advanced. Hmm. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/