Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rVNQ4-00GY8b-FR for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Feb 2024 03:07:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rVNQ3-000bvf-Cg for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Feb 2024 03:07:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rVNQ2-000bsu-2U for pgsql-hackers@lists.postgresql.org; Thu, 01 Feb 2024 03:07:15 +0000 Received: from wfhigh8-smtp.messagingengine.com ([64.147.123.159]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rVNPy-004Qez-EX for pgsql-hackers@lists.postgresql.org; Thu, 01 Feb 2024 03:07:12 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id 774AA180007F; Wed, 31 Jan 2024 22:07:07 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute2.internal (MEProxy); Wed, 31 Jan 2024 22:07:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1706756826; x=1706843226; bh=CWqRsEtCsX qs9elbth2kADrwGXgFbh2+DczdYj3mN2c=; b=uzzv7ZVRzDVvwNYCCcV4tabRgK X8c8EFzNiYMZt9ZrxVfjUSHfHtHE9cDzlvwwpSMfd4C6RA3sOaNSOOIWZIE4PLKH kly8XDbedd81q3IT+uxvJVh/oxscdI/Kjqr6sDw6kYNXs9UeGxxTWeG1igLqgDe9 cF0FuYGvYZlhXSuu9+zLjDy4NsNQmSTOARO4H400oC55OmS7If3s83r9OKv43swN oX2zzAdzj15olRunYE1JMpIgZqMB5H0RwrH/JqtqXmbYEpVfsepKAZHH9Y9VcpML B2PYRg9BnqlqvrcWW0WBQyaRcZSLB3X0jRLQi+K3jlnRNc9hcjvvK3cRhKkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1706756826; x=1706843226; bh=CWqRsEtCsXqs9elbth2kADrwGXgF bh2+DczdYj3mN2c=; b=FquIElf9Hpn1i446zqn6J3y3kEyr2Iw0qFgpTm00PXLg 2UcEtNbhtXmeoKGjlbQMhYe6nDMh45iyw5U1857YM7gZaRZp0WbpNMul14iCtdJI p1vrpSy7bDvJfy87fZKKmOAlURs03CxYgo+/7kZxLjTNcX8LaOZ1bS4ngXtHIU5T B6BFa3G3VoAnzR9FSqIkufYsUCmTNvPrhzI2B0VfUGKudDHYqAbW2DuqAx9uDGCP yUwccDo2MFCH2CgxDw0K6YChbzuXTBiMr/EgiI8kRD6dniTshVpjtZAtTJgeRpC7 tttTnX/Z3zco562NOXyymaAbkJSmsAx7ig66RhuY2Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedutddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfgfhu lhgvrhcuvfgrvhgvihhrrgdfuceovghulhgvrhesvghulhgvrhhtohdrtghomheqnecugg ftrfgrthhtvghrnhepgfffjedviedvkedviedvteduieekudeivedthffhuddvteegleet ieffkeeghfdvnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegvuhhlvghrsegv uhhlvghrthhordgtohhm X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A34A15A0092; Wed, 31 Jan 2024 22:07:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 MIME-Version: 1.0 Message-Id: <6793c99e-9bb4-4395-8e00-21d7074445c9@app.fastmail.com> In-Reply-To: References: <5ac50071-f2ed-4ace-a8fd-b892cffd33eb@www.fastmail.com> <4710d895-689a-4ae6-b8e3-344286dbf970@app.fastmail.com> <96e3b739-d63d-4d35-90a3-7869465b7167@eisentraut.org> <2736443c-58e3-42df-8cc4-8c66106e3da5@app.fastmail.com> <1cd45c1e-8ed1-42fc-9357-f1c43e0d6ac8@app.fastmail.com> <80ce3f65-7ca3-471e-b1a4-24ac529ff4ea@app.fastmail.com> Date: Thu, 01 Feb 2024 00:05:23 -0300 From: "Euler Taveira" To: "kuroda.hayato@fujitsu.com" , "pgsql-hackers@lists.postgresql.org" Cc: "vignesh C" , "Michael Paquier" , "Peter Eisentraut" , "Andres Freund" , "Ashutosh Bapat" , "Amit Kapila" , "Shlok Kyal" Subject: Re: speed up a logical replica setup Content-Type: multipart/alternative; boundary=767cf882365c41509da5a18b079d3a7b List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --767cf882365c41509da5a18b079d3a7b Content-Type: text/plain On Wed, Jan 31, 2024, at 11:09 PM, Hayato Kuroda (Fujitsu) wrote: > > > Why? Are you suggesting that the dry run mode covers just the verification > part? If so, it is not a dry run mode. I would expect it to run until the end > (or until it accomplish its goal) but *does not* modify data. For pg_resetwal, > the modification is one of the last steps and the other ones (KillFoo > functions) that are skipped modify data. It ends the dry run mode when it > accomplish its goal (obtain the new control data values). If we stop earlier, > some of the additional steps won't be covered by the dry run mode and a failure > can happen but could be detected if you run a few more steps. > > > > Yes, it was my expectation. I'm still not sure which operations can detect by the > dry_run, but we can keep it for now. The main goal is to have information for troubleshooting. > > Good point. I included a check for pg_create_subscription role and CREATE > privilege on the specified database. > > > > Not sure, but can we do the replication origin functions by these privilege? > According to the doc[1], these ones seem not to be related. Hmm. No. :( Better add this check too. -- Euler Taveira EDB https://www.enterprisedb.com/ --767cf882365c41509da5a18b079d3a7b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Jan 31,= 2024, at 11:09 PM, Hayato Kuroda (Fujitsu) wrote:
>
Why? Are you = suggesting that the dry run mode covers just the verification
<= div>part? If so, it is not a dry run mode. I would expect it to run unti= l the end
(or until it accomplish its goal) but *does not*= modify data. For pg_resetwal,
the modification is one of = the last steps and the other ones (KillFoo
functions) that= are skipped modify data. It ends the dry run mode when it
accomplish its goal (obtain the new control data values). If we stop ea= rlier,
some of the additional steps won't be covered by th= e dry run mode and a failure
can happen but could be detec= ted if you run a few more steps.
>

Yes, it was my expectation. I'm still not sure which operations= can detect by the
dry_run, but we can keep it for now.

The main goal is to have informa= tion for troubleshooting.


Good point. I included a check = for pg_create_subscription role and CREATE
privilege on th= e specified database.
>

No= t sure, but can we do the replication origin functions by these privileg= e?
According to the doc[1], these ones seem not to be rela= ted.

Hmm. No. :( Better add th= is check too.


--
Euler Ta= veira

--767cf882365c41509da5a18b079d3a7b--