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 1pKyxl-0002nt-5e for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 09:54:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pKyxi-00071g-VK for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 09:54:30 +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 1pKyxi-00071T-0Y for pgsql-hackers@lists.postgresql.org; Thu, 26 Jan 2023 09:54:30 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKyxe-0008JB-8K for pgsql-hackers@lists.postgresql.org; Thu, 26 Jan 2023 09:54:29 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id E4D0D581E60; Thu, 26 Jan 2023 04:54:24 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 26 Jan 2023 04:54:24 -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=1674726864; x=1674734064; bh=r d5g4B8ii9RWjUXY8iSg8GXWWJIw9sJv0pnf7xbtMDw=; b=EHo0UbkEOYRqw4F20 yoEd+/iEI3tzngJaM+mr0xr6M3GaAWZ8J1KTdByKf6tEEGLJAX3kFx/+Vjffj94L NYS5Pols1Da5HHRi1H78UTjx0vmWRoxDKAjhGqLbpN8wc4i5xFzql455YF031hu8 sqfYRzLqV+fmack3kOaeyofFdrG5cxeSLUYIT1I+oS2GP+gkyTf7HbwoQKhw1+j8 bbniSnlBgG5qC9QY3GML9RhGVohi1KyNWsxlOkCHm6k66Vsjs2/d8U3Sfx+QcpAL oCWcgaW/08aBv68HUIgSe9yN1k4PtzErsNkSy9bxTfryhp2CCB/yRQENLpvf7gbD cL7Ww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddvgedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Jan 2023 04:54:24 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 8661C98; Thu, 26 Jan 2023 10:42:41 +0100 (CET) Date: Thu, 26 Jan 2023 10:42:41 +0100 From: Alvaro Herrera To: "Drouvot, Bertrand" Cc: PostgreSQL Hackers Subject: Re: Helper functions for wait_for_catchup() in Cluster.pm Message-ID: <20230126094241.yjofprg2xcu43kop@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <606daf52-fcc8-bc5e-6e7a-75d9f7c29532@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Jan-26, Drouvot, Bertrand wrote: > On 1/24/23 7:27 PM, Alvaro Herrera wrote: > > 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. > > Agree but there is one place where the node passed as the second argument is not the "$self": > > src/bin/pg_rewind/t/007_standby_source.pl:$node_b->wait_for_write_catchup('node_c', $node_a); > > So it looks like there is still a need for wait_for_write_catchup(). Hmm, I think that one can use the more general wait_for_catchup. > > 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); > > Yeah, but same here, there is places where the node passed as the second argument is not the "$self": > > src/bin/pg_rewind/t/007_standby_source.pl:$node_b->wait_for_replay_catchup('node_c', $node_a); > src/test/recovery/t/001_stream_rep.pl:$node_standby_1->wait_for_replay_catchup($node_standby_2, $node_primary); > src/test/recovery/t/001_stream_rep.pl:$node_standby_1->wait_for_replay_catchup($node_standby_2, $node_primary); > src/test/recovery/t/001_stream_rep.pl: $node_standby_1->wait_for_replay_catchup($node_standby_2, $node_primary); > > So it looks like there is still a need for wait_for_replay_catchup() with 2 parameters. Ah, cascading replication. In that case, let's make the second parameter optional. If it's not given, $self is used. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica" (Irulan)