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 1pKOBz-00067n-Sb for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jan 2023 18:38:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pKOBy-0002mI-PM for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jan 2023 18:38:46 +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 1pKOBx-0002m8-Vq for pgsql-hackers@lists.postgresql.org; Tue, 24 Jan 2023 18:38:46 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKOBv-0000X2-9A for pgsql-hackers@lists.postgresql.org; Tue, 24 Jan 2023 18:38:44 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 14CF5581E4E; Tue, 24 Jan 2023 13:38:41 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 24 Jan 2023 13:38:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1674585521; x=1674592721; bh=R miSQrjbeEzVQJ06zsz5E1aMBTz5iwT9mAZ4nAvAF9s=; b=A/FakZCzjelONpBnw 5r5BSgrcu0XzrPycO5A9lJNGYUqS7mzvemN76Kjd3G+ZZJQMm+kAJ0bAJTc+cBMq 2pakGOVFsZHfvbWddviF71MWGp9b1yX+n+uIXHzSDOXn1QnvOZ2U9adZ/A95dHZL ZosSsjnedHAWMUbTFdh5G9bavIxSU9TdCQ9vGcqovv9MEYGaeKOzHcQxGGJN42le OBvdN+niIplIH7C5mkPgu2bLo3p0Nd9BNhR8WAocGa1X1zhgIvgKc7HgKf4jZ1fP ZwCgpaOerZPiY6FeNIDNehEuq7wUDN1N4VXa/u2ZSHS2Z34gdQw6isdFQ+nk8J/9 0CInQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddvtddguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeej keffgfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl vhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 Jan 2023 13:38:40 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id DEC0F9C; Tue, 24 Jan 2023 19:27:28 +0100 (CET) Date: Tue, 24 Jan 2023 19:27:28 +0100 From: Alvaro Herrera To: "Drouvot, Bertrand" Cc: PostgreSQL Hackers Subject: Re: Helper functions for wait_for_catchup() in Cluster.pm Message-ID: <20230124182728.bp6cyo74c77hb4vn@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2198c60b-9a6c-79a5-bb35-81f1ac3113bd@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Looking again, I have two thoughts for making things easier: 1. I don't think wait_for_write_catchup is necessary, because calling wait_for_catchup() and omitting the 'mode' and 'lsn' arguments would already do the same thing. So what we should do is patch places that currently give those two arguments, so that they don't. 2. Because wait_for_replay_catchup is an instance method, passing the second node as argument is needlessly noisy, because that's already known as $self. So we can just say $primary_node->wait_for_replay_catchup($standby_node); -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/