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 1mGOzF-0000QQ-Rc for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Aug 2021 17:04:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mGOzE-0001GS-Q5 for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Aug 2021 17:04: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 1mGOzE-0001GK-Hb for pgsql-hackers@lists.postgresql.org; Wed, 18 Aug 2021 17:04:20 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mGOzC-00009i-2v for pgsql-hackers@postgresql.org; Wed, 18 Aug 2021 17:04:20 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BD36E5C014D; Wed, 18 Aug 2021 13:04:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 18 Aug 2021 13:04:16 -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=RHcq8qRd5AFo7vKMshcEluzHfyDwFy3PWu9XwWvnz5Q=; b=q+QJ49uV tJ4bsv9uRpwskPc7RsZK68RCMWZXO2OLqTVBvohAv0eKk0lOgvTqHwQjTpC4IfcS cTvAmE3rBjfK/8LbyOIu82BQy4MzCoIkjEg/75/CX8YYcCHng1TfjbB66RY3c3Pr p6YhE9mjpcugjAouOh+x4ubwnaiQsPehfzxkFdXPif94GvRbl1BrJ4vAmxouZbT/ FP8+q9NNRukXzYIHnP9Omo3FGz5bDJEdMDzcN0b+7X0ye39jyVQ7RpWJezYz9Mlw sBqQVtsZ1zDb1Dg9jmibHVXpAgn7pk36qky948e5Hk4COSoMdlGEL0xxmitiyc4Q UilQ3LlLvimaqQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleehgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpedfrghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrghdfuceorghlvhhhvghrrhgvsegrlhhvhh drnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhephfdufedthfelveegjedtffdu leekiedugfdtgfdttdevteejleetgefhueeigfetnecuffhomhgrihhnpegvnhhtvghrph hrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Aug 2021 13:04:14 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id E58A72A093F; Wed, 18 Aug 2021 13:04:11 -0400 (-04) Date: Wed, 18 Aug 2021 13:04:11 -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: <202108181704.y3xssxde4qsf@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202108172232.nqewuhgxhxty@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Aug-17, alvherre@alvh.no-ip.org wrote: > 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. Reading the comments on walwriter.c I am hesitant of having walwriter do it: > * Because the walwriter's cycle is directly linked to the maximum delay > * before async-commit transactions are guaranteed committed, it's probably > * unwise to load additional functionality onto it. For instance, if you've > * got a yen to create xlog segments further in advance, that'd be better done > * in bgwriter than in walwriter. So that comment suggests that we should give the responsibility to bgwriter. This seems good enough to me. I suppose if bgwriter has a long run of buffers to write it could take a little bit of time (a few hundred milliseconds?) but I think that should be okay. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "No renuncies a nada. No te aferres a nada."