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 1mGPY2-0001Qd-LY for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Aug 2021 17:40:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mGPY0-00012U-VC for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Aug 2021 17:40: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 1mGPY0-0000yA-0c for pgsql-hackers@lists.postgresql.org; Wed, 18 Aug 2021 17:40:16 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mGPXt-0001VJ-Uy for pgsql-hackers@postgresql.org; Wed, 18 Aug 2021 17:40:14 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 880CA5C01AC; Wed, 18 Aug 2021 13:40:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 18 Aug 2021 13:40:08 -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=eyBrLX/YUcl6DIdQykM+CTp9Xlftx0Zz36EoT+/4Ikk=; b=D+CV5hd9 E1yYi57wVbxM4S+0wGQFr9BWl8uxC/rhdPYFDl/gNfxxPSKxSOrpoVfUa2kyUrmJ 5KD1GXE+UurdOo/oEWbROEGoXOJZAjBvp2EhOhW2PW4YFaSEzYO8B9PQS5XxMFcP XyBOU/C8rdUBM5uiuGZrdmh+R4YN3Aowwg5FEDXhMwFSuhEM71VNCjlb4eXimYsq qSE5YEL0C51o9M6n/RQ9JP6EqrCEGo+IE4UZIT8vZAYLHd1ui58Z7FcfJ3uBtS3j weOA6+hY5112mo4HoeSGfCdSQ9llhGKAnhmFjN5QBaoERbv/PnjR3IytTQt4awOa zHHNVyB8noMqrg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleehgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpedfrghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrghdfuceorghlvhhhvghrrhgvsegrlhhvhh drnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhepvdehleduvddtueeigedvveet feetvefftdduleelleeuheevtdelffelueduhfetnecuffhomhgrihhnpegvnhhtvghrph hrihhsvggusgdrtghomhdplhifnhdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprd horhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Aug 2021 13:40:06 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id B2B222A093F; Wed, 18 Aug 2021 13:40:03 -0400 (-04) Date: Wed, 18 Aug 2021 13:40:03 -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: <202108181740.zmdxsi3uci2k@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: > On 8/18/21, 10:06 AM, "alvherre@alvh.no-ip.org" wrote: > > 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. > > Do you think bgwriter should be the only caller of > NotifySegmentsReadyForArchive(), or should we still have XLogWrite() > call it? I think XLogWrite should absolutely be the primary caller. The one in bgwriter should be a backstop for the case you describe where the flush pointer advanced past the registration point in XLogInsertRecord. I realize this means there's a contradiction with my previous argument, in that synchronous transaction commit calls XLogWrite at some point, so we *are* putting the client-connected backend in charge of creating the notify files. However, that only happens on transaction commit, where we already accept responsibility for the WAL flush, not on each individual XLOG record insert; also, the WAL writer will take care of it sometimes, for transactions that are long-enough lived. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "How strange it is to find the words "Perl" and "saner" in such close proximity, with no apparent sense of irony. I doubt that Larry himself could have managed it." (ncm, http://lwn.net/Articles/174769/)