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 1mICrk-0003q6-89 for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Aug 2021 16:32:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mICri-0003la-2d for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Aug 2021 16:32:02 +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 1mICrh-0003lR-Qp for pgsql-hackers@lists.postgresql.org; Mon, 23 Aug 2021 16:32:01 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mICrb-0007EF-G1 for pgsql-hackers@postgresql.org; Mon, 23 Aug 2021 16:32:00 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7EB745C0114; Mon, 23 Aug 2021 12:31:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 23 Aug 2021 12:31:54 -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=TyGG2SPr+wltYBkR96jyt7IFQ+uoZURZWBO78/krWGQ=; b=PX0I3vpm KTC083j0/qentKQMp7Ib5NL8p/kCmYWgmmX39VMQYjfjo8M0OaxBYpF9iGPGwhHC 7hXWuK8lxLQn0FYFetJCb/UwM9/RAMqOEXY5g8MtU66BZ2SEAcez9PJq7gne3jWF 5JL3Rz3FxjIys0DQhFgPwXv9rnftwd/0PcK31R9ltyJ6Zk9FmZiau20DYVmqce4A PG/ysU3Zr4z5JZGyOacH2vQQgclClCg3zcJNwiM3BLu1ZAhG6Op9eWxlvpXU8v7A 7PUNWyWVjkjWOlZHUgcvGv/8sbhqrZPnPhkNGC6rM0bluxZwGs0n8lQx8KLyjVrS yHISO9KcvJwNQQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddthedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomhepfdgrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgfdcuoegrlhhvhhgvrhhrvgesrghlvh hhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpefhudeftdfhleevgeejtdff udelkeeiudfgtdfgtddtveetjeelteeghfeuiefgteenucffohhmrghinhepvghnthgvrh hprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 23 Aug 2021 12:31:51 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id CD5B62A0283; Mon, 23 Aug 2021 12:31:48 -0400 (-04) Date: Mon, 23 Aug 2021 12:31:48 -0400 From: "alvherre@alvh.no-ip.org" To: "Bossart, Nathan" Cc: Robert Haas , 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: <202108231631.wpeh7fk2j7oz@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-23, Bossart, Nathan wrote: > Hm. My expectation would be that if there are no registrations, we > cannot create .ready files for the flushed segments. The scenario > where I can see that happening is when a record gets flushed to disk > prior to registration. In that case, we'll still eventually register > the record and wake up the WAL writer process, which will take care of > creating the .ready files that were missed earlier. Is there another > case you are thinking of where we could miss registration for a cross- > segment record altogether? I'm thinking of the case where no record cross segment boundaries ever. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/