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 1pKyfB-0001d8-5q for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 09:35: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 1pKyf9-0003rT-Qf for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 09:35:19 +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 1pKyf9-0003rK-EA for pgsql-hackers@lists.postgresql.org; Thu, 26 Jan 2023 09:35:19 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pKyf2-0004Hz-I5 for pgsql-hackers@lists.postgresql.org; Thu, 26 Jan 2023 09:35:18 +0000 Received: by mail-wr1-x42c.google.com with SMTP id q5so1166703wrv.0 for ; Thu, 26 Jan 2023 01:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=bNHSOyYjkYdU2xtYMB8TjSwe02YtboXwsu5SWi4L+Fw=; b=UAd+U9zcZP7PqI662+2UK33zOpmlW9AmkITqg/RIxk6iMiO6Ur8g3YwXnJqNEnpM6F zcAbFv10vk0tntvZwbFo61PirvUqQmP9oRTBy9IW/OSRQpX1R1mEmn/H91jXG0t9+TqH M9lkkWFKZ1fry8H/bLiPCG6UDEFSHd0wan7Zs5tTwZ2iqH/uL4EjX6iu5TNKposq5CVr povT5vobR7oKIMG1yOyKMAaxGSACewWmzsako6SBM3picjJZcFJDYqm95G1heJH5i9N4 ddmxxzpKrzKCcv/4S6VKaQGLBAHAE+QuWRBoknl+CuTwbdRH4sFqMJAEgmbekIQhpKsU QnCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bNHSOyYjkYdU2xtYMB8TjSwe02YtboXwsu5SWi4L+Fw=; b=bAZxPVpcl59+E3NqkU/dNVJugNJyphxwnuGq/S9TiTd/ij3IZf5PCImm27R8V6uhda +SSL92BRi8C3zHis720KkIdUE+G9XMVX+epUKD7MXCI5RJCdXWCX2SXp8BET2zBegwZp /Uf5DsAmteATDZgtoOy633R+4oJve8BJFD5GjETu6mRbp2w279dEzIBNZFKbavyLHW78 feQmq0N2NbRZCKn162VjaFOHydNcG7L0A7mWOJgCvXEfzYWmdEdd1wXB1Nx14Q8r6mog XNm+AYY6kaYsbMwl9G0QvmTAqaA6Ab824UCB1A251ilObB0rJZjSrGUg0CtAntsfOj7c /cfg== X-Gm-Message-State: AO0yUKWAgftt76zXajNgmJdIrmIe6AuDc7FIVZxDyayH1Qqzcu2vBKwB PkTl4u7oQniZbIs+5USP/Kw= X-Google-Smtp-Source: AK7set/FnTr2sYurcWTuSdp7rOGybCI8HIU/3ywFmysK1peTtqWdYFTuc63CjX6F0Wxdy2EnnyvNFg== X-Received: by 2002:adf:f88e:0:b0:2bf:b047:d4ab with SMTP id u14-20020adff88e000000b002bfb047d4abmr7687453wrp.13.1674725710908; Thu, 26 Jan 2023 01:35:10 -0800 (PST) Received: from [192.168.15.226] ([54.239.6.190]) by smtp.gmail.com with ESMTPSA id m4-20020adffa04000000b002366dd0e030sm747316wrr.68.2023.01.26.01.35.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Jan 2023 01:35:10 -0800 (PST) Message-ID: <606daf52-fcc8-bc5e-6e7a-75d9f7c29532@gmail.com> Date: Thu, 26 Jan 2023 10:33:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Helper functions for wait_for_catchup() in Cluster.pm Content-Language: en-US To: Alvaro Herrera Cc: PostgreSQL Hackers References: <20230124182728.bp6cyo74c77hb4vn@alvherre.pgsql> From: "Drouvot, Bertrand" In-Reply-To: <20230124182728.bp6cyo74c77hb4vn@alvherre.pgsql> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 1/24/23 7:27 PM, Alvaro Herrera wrote: > 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. > 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(). > 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. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com