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 1rLQ6J-007o3D-Ff for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2024 15:57:43 +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 1rLQ6H-00Dh5D-Gt for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2024 15:57:41 +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 1rLQ6H-00Dh54-2c for pgsql-hackers@lists.postgresql.org; Thu, 04 Jan 2024 15:57:41 +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 1rLQ6E-00Dicf-68 for pgsql-hackers@lists.postgresql.org; Thu, 04 Jan 2024 15:57:39 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 578273200B74; Thu, 4 Jan 2024 10:57:36 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute2.internal (MEProxy); Thu, 04 Jan 2024 10:57:37 -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=1704383855; x=1704470255; bh=PkuVycnin3 OxWrZmSjEynso8N0m7C+rQakM4OXKShl8=; b=fwooiBDxs+UgalBXLOPmn6KjvW XYg84AELYD3JsorFhuUWTUTQ5y+xI6F7qCzLxb/pdmblB6III0Mb32Z69qYwY9Ap /9aUG7CDtbS04DZGTR7BYPTIGxFuWTk0AckfCmcy1sUCqPJRFe5e3dU6EbqPvfCZ fseL2VSQi8Sr+Yd31uQ/rugU9OXfIuycqyot/UHsNgpa2jIsWe5X1nIM9BFawzGQ aJd3kgqNV/XCAleaipBeX+pdtSRMVcdtAb1Z4GQSl5NkGOs+w8dsS4rkiD/ipHH2 ds//tvJuN6ppXdCDWiqYRk+U3KeNf80ndHfvqfRz8BaxDavmokLjUswrbpjA== 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=1704383855; x=1704470255; bh=PkuVycnin3OxWrZmSjEynso8N0m7 C+rQakM4OXKShl8=; b=9dQKBvuIG0mKb+6mc5+Zx89KrMbKKk0NvG/z1iRp/ICn VztK0wXVW/3Urjrmo1TKB4zqas2NnGP89PTPhnl8wKXm8y9ICVQQvpEzupg/sNYU Kp1FH1trvKS84UQs52KEpgiAfeXwmLvyXTB14iei+7ucdUIrdHBz2p0smjqf92NX X5mlh1EOzCFY9u3ZW+x1Hcwlm7ZSz9TiuybTueXn/9CSokEqfbyC8vDbEFQI1XEI 3rtGHbC9kzSIODiXMa4XyQPuT7PWqf8zmFgN/L5jXtYiAqtzLrRtj0IMW0kQ37DO 4d6SDmamLaEelDL8chW7yA3IzkV731DicJtyOjDAhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdegjedgkedvucetufdoteggodetrfdotf 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 7F40015A0092; Thu, 4 Jan 2024 10:57:35 -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: <69a0437a-db35-4366-834e-fbcdad6fb4bf@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> Date: Thu, 04 Jan 2024 12:57:15 -0300 From: "Euler Taveira" To: "Amit Kapila" Cc: "vignesh C" , "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=a492a7de8c2046978da11eaf50758ee7 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --a492a7de8c2046978da11eaf50758ee7 Content-Type: text/plain On Thu, Jan 4, 2024, at 3:05 AM, Amit Kapila wrote: > Won't it be a better user experience that after setting up the target > server as a logical replica (subscriber), it started to work > seamlessly without user intervention? If we have an option to control the replication slot removal (default is on), it seems a good UI. Even if the user decides to disable the replication slot removal, it should print a message saying that these replication slots can cause WAL retention. > > The initial version had an option to stop the subscriber. I decided to > > remove the option and stop the subscriber by default mainly because (1) it is > > an extra step to start the server (another point is that the WAL retention > > doesn't happen due to additional (synchronized?) replication slots on > > subscriber -- point 2). It was a conservative choice. If point 2 isn't an > > issue, imo point 1 is no big deal. > > > > By point 2, do you mean to have a check for "max replication slots"? > It so, the one possibility is to even increase that config, if the > required max_replication_slots is low. By point 2, I mean WAL retention (sentence inside parenthesis). -- Euler Taveira EDB https://www.enterprisedb.com/ --a492a7de8c2046978da11eaf50758ee7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Jan 4, = 2024, at 3:05 AM, Amit Kapila wrote:
Won't it be a better user experience that afte= r setting up the target
server as a logical replica (subsc= riber), it started to work
seamlessly without user interve= ntion?

If we have an option to= control the replication slot removal (default is on),
it = seems a good UI. Even if the user decides to disable the replication slo= t
removal, it should print a message saying that these rep= lication slots can
cause WAL retention.

=
> The initi= al version had an option to stop the subscriber. I decided to
<= div>> remove the option and stop the subscriber by default mainly bec= ause (1) it is
> an extra step to start the server (ano= ther point is that the WAL retention
> doesn't happen d= ue to additional (synchronized?) replication slots on
>= subscriber -- point 2). It was a conservative choice. If point 2 isn't = an
> issue, imo point 1 is no big deal.
&= gt;

By point 2, do you mean to have a check= for "max replication slots"?
It so, the one possibility i= s to even increase that config, if the
required max_replic= ation_slots is low.

By point 2= , I mean WAL retention (sentence inside parenthesis).


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

--a492a7de8c2046978da11eaf50758ee7--