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 1rLPxb-007nQr-Ud for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2024 15:48:44 +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 1rLPxa-00DdIE-CN for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2024 15:48:42 +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 1rLPxZ-00DdHS-D5 for pgsql-hackers@lists.postgresql.org; Thu, 04 Jan 2024 15:48:42 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rLPxW-00DiZ2-E4 for pgsql-hackers@lists.postgresql.org; Thu, 04 Jan 2024 15:48:40 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 1F1FD3200BC6; Thu, 4 Jan 2024 10:48:36 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute2.internal (MEProxy); Thu, 04 Jan 2024 10:48:36 -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=fm3; t=1704383315; x=1704469715; bh=/Tm9z6Yubf QbY5b4sSv95QdmrTjwR0TV51J3oRqx4uI=; b=IFnOmh/tdIR/SnqeZTNimRJuPg 6L8kEhPf7ocgsiTxKC96O5fAt30Yi0vNcKJ3QudxYRR1ehrinqMcD/SXYM1M+KUU qkEZW8gFS9/UqkicgORY0o5holUZxn/TouhV10PP0ZiPmOiqZBAX2i67O6dTT3UQ QzPUR9wvJYRWsu4k5+IUMglgLbmMEtrW40sdTPSW3qeulGtu/vyVnuqPPAA1VhU8 /1J1zSea26MY6gYeB2h0ho0MPs4VwHof3gO/13YU5gnILriQta1SPTjwv08HQNyf Hv3dRDdpn4AZaCBaI4WzrWfNx1ih69K6bAVnSn4KPBG5mhoW6WIxR5qTepbA== 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= fm2; t=1704383315; x=1704469715; bh=/Tm9z6YubfQbY5b4sSv95QdmrTjw R0TV51J3oRqx4uI=; b=EUv3HNf3jMB217mEpK37xebmZBGcpKM4OmUDttrzQMaU +rPRVDt/dYzJYsu0O9+WFxR4REPv+7I3OrECck18bVKmYzjtbkox1pSzqNptd0/7 QQCh9mn7ZIH9z5o7jLgIap1vR1K85hFJyzOG0Jpw3AqVqvlaEReoXwVGTdD3h72o QrkRhQdRB+/F4jAPgf2f6cVtvSSG85mZtXXi0JW3++sXmpWRduVtslTt/4AmmSWc U05oUH9MRfccM3Ztqkob7z4ugmJ06rtaGH6Hwb2F63ACxFDgxtFWqVQCNXiwuSwQ G/oa08Y6Jnx1gBKN9Rm9RBHLqDTXbOZvi0zhlCdTbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdegjedgkeduucetufdoteggodetrfdotf 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 184F115A0093; Thu, 4 Jan 2024 10:48:34 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 MIME-Version: 1.0 Message-Id: <9fd3018d-0e5f-4507-aee6-efabfb5a4440@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> <270ad9b8-9c46-40c3-b6c5-3d25b91d3a7d@app.fastmail.com> Date: Thu, 04 Jan 2024 12:48:03 -0300 From: "Euler Taveira" To: "Amit Kapila" Cc: "Michael Paquier" , "Peter Eisentraut" , pgsql-hackers@lists.postgresql.org, "Andres Freund" , "Ashutosh Bapat" Subject: Re: speed up a logical replica setup Content-Type: multipart/alternative; boundary=ccb5088e812b489ebd480586b0c4dfd0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --ccb5088e812b489ebd480586b0c4dfd0 Content-Type: text/plain On Thu, Jan 4, 2024, at 2:41 AM, Amit Kapila wrote: > So, you also seem to be saying that it is not required once > pg_subscriber has promoted it. So, why it should be optional to remove > physical_replication_slot? I think we must remove it from the primary > unless there is some other reason. My point is to *always* remove the primary_slot_name on primary. > My point is to not have an additional slot and keep a comment > indicating that we need an extra slot once we add pg_basebackup > support. Got it. > > 3. How about sync slots on the physical standby if present? Do we want > > to retain those as it is or do we need to remove those? We are > > actively working on the patch [1] for the same. > > > > > > I didn't read the current version of the referred patch but if the proposal is > > to synchronize logical replication slots iif you are using a physical > > replication, as soon as pg_subscriber finishes the execution, there won't be > > synchronization on these logical replication slots because there isn't a > > physical replication anymore. If the goal is a promotion, the current behavior > > is correct because the logical replica will retain WAL since it was converted. > > > > I don't understand what you mean by promotion in this context. If > users want to simply promote the standby then there is no need to do > additional things that this tool is doing. ENOCOFFEE. s/promotion/switchover/ > > However, if you are creating a logical replica, this WAL retention is not good > > and the customer should eventually remove these logical replication slots on > > the logical replica. > > > > I think asking users to manually remove such slots won't be a good > idea. We might want to either remove them by default or provide an > option to the user. Am I correct that the majority of the use cases these replication slots will be useless? If so, let's remove them by default and add an option to control this behavior (replication slot removal). -- Euler Taveira EDB https://www.enterprisedb.com/ --ccb5088e812b489ebd480586b0c4dfd0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Jan 4, = 2024, at 2:41 AM, Amit Kapila wrote:
So, you also seem to be saying that it is not = required once
pg_subscriber has promoted it. So, why it sh= ould be optional to remove
physical_replication_slot? I th= ink we must remove it from the primary
unless there is som= e other reason.

My point is to= *always* remove the primary_slot_name on primary.

<= blockquote type=3D"cite" id=3D"qt" style=3D"">
My point is to not ha= ve an additional slot and keep a comment
indicating that w= e need an extra slot once we add pg_basebackup
support.

Got it.

> 3. How about sync s= lots on the physical standby if present? Do we want
> t= o retain those as it is or do we need to remove those? We are
<= div>> actively working on the patch [1] for the same.
&= gt;
>
> I didn't read the current vers= ion of the referred patch but if the proposal is
> to s= ynchronize logical replication slots iif you are using a physical
> replication, as soon as pg_subscriber finishes the executio= n, there won't be
> synchronization on these logical re= plication slots because there isn't a
> physical replic= ation anymore. If the goal is a promotion, the current behavior
> is correct because the logical replica will retain WAL since = it was converted.
>

I don'= t understand what you mean by promotion in this context. If
users want to simply promote the standby then there is no need to do
additional things that this tool is doing.

ENOCOFFEE. s/promotion/switchover/
<= br>
> Howeve= r, if you are creating a logical replica, this WAL retention is not good=
> and the customer should eventually remove these logi= cal replication slots on
> the logical replica.
>

I think asking users to manuall= y remove such slots won't be a good
idea. We might want to= either remove them by default or provide an
option to the= user.

Am I correct that the m= ajority of the use cases these replication slots will be
u= seless? If so, let's remove them by default and add an option to control= this
behavior (replication slot removal).
<= br>

--
Euler Taveira
EDB   https://www.enterprisedb.com/

= --ccb5088e812b489ebd480586b0c4dfd0--