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 1rox0f-004HO8-ER for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 02:57:58 +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 1rox0d-00ACl7-St for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 02:57:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rox0d-00ACky-IF for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2024 02:57:56 +0000 Received: from wfout4-smtp.messagingengine.com ([64.147.123.147]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rox0a-006Vlx-T2 for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2024 02:57:55 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.west.internal (Postfix) with ESMTP id C4F0B1C000E3; Mon, 25 Mar 2024 22:57:49 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute2.internal (MEProxy); Mon, 25 Mar 2024 22:57:50 -0400 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=1711421869; x=1711508269; bh=KYViIFdBcD dnTmY/+9G6GcpfEp7hIRXmozAW3WMgtxw=; b=MmabKJtJBnd9SZG0LyJAmVoGCo c1Ac//YJQl7QjJZqrnYbiHAz+SsLOxFYEU6tWNJisVlYmvzCXp7BoURBD6DDsNzm 6T3NKEKDX5CmZ8N+XwYZ9hRbN2DyFgmMVdfB8PLrrxqKXV2RKdbDRhzEiesr/DpY HBVbiQGJkNKloOmDOeJTQYmxggi5FDlb9glOUbJx89CuGuVMx3xE/tWq+Sa63qZo bW6gFFnm2gErY0L2Rc/kphA+61YxvqjKgKyX0U7KEGLe3Sn87OqQKpjH+OhT71VS Be7wAo0lGaa/hzGVzS+nSRFcZaoaQTgdLjYdHrnM7n40dQtrM6U7DYyiGvzQ== 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=1711421869; x=1711508269; bh=KYViIFdBcDdnTmY/+9G6GcpfEp7h IRXmozAW3WMgtxw=; b=Z7OBn4YgCvwI4KPEXfft6aOSdG/yP/Xr8ryVNDHZeXRS DSQBHU3GYgYq5U7xrfNEzCX1EhorByO1dv0EIkYgDliPfQeOtXt/qEQXAUTEMSjo j6CmQsaZSQld5dY6lB/6GQjBhoDz7NsFhgHZH1auV9ljXDcHnYG8gh7+LTYg4Dt4 K1EjBVmttyQGNKUSgh1nwFBe6qkeJwrlZDTqZY8qsKq3DNJamNUdNnBvGisPLn9v h3eopY0NZ8kTVxC1+uHEZhAfcJDV2SY1Wa73hZUqLMVyq+AJgI79XcFuVD9DE6OA LKXLaVY2mlX2xngdnSEmw9hmN0pigmGT6VDGRkqYZA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduvddgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedfgfhu lhgvrhcuvfgrvhgvihhrrgdfuceovghulhgvrhesvghulhgvrhhtohdrtghomheqnecugg ftrfgrthhtvghrnhepgeeugeelheefheegvefggffhgffgteeuudevvdekhedvvdekgfeh keeitedvgedvnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegvuhhlvghrsegv uhhlvghrthhordgtohhm X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E4E1A15A0092; Mon, 25 Mar 2024 22:57:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-328-gc998c829b7-fm-20240325.002-gc998c829 MIME-Version: 1.0 Message-Id: <6aa1b0d7-a4e9-46b1-9990-3ae1d22e1952@app.fastmail.com> In-Reply-To: References: <9a9c7e65-c47b-4400-a63e-ac6169c0860e@app.fastmail.com> <40595e73-c7e1-463a-b8be-49792e870007@app.fastmail.com> <6423dfeb-a729-45d3-b71e-7bf1b3adb0c9@enterprisedb.com> <2f0b73f3-e7c0-4e95-9712-1993442a6b64@app.fastmail.com> <34637e7f-0330-420d-8f45-1d022962d2fe@app.fastmail.com> <7a970912-0b77-4942-84f7-2c9ca0bc05a5@eisentraut.org> <44de4e04-db22-40ed-8ba9-46387dc8bf83@app.fastmail.com> <3fa9ef0f-b277-4c13-850a-8ccc04de1406@eisentraut.org> Date: Mon, 25 Mar 2024 23:57:27 -0300 From: "Euler Taveira" To: "Amit Kapila" , "Peter Eisentraut" Cc: "Shlok Kyal" , "kuroda.hayato@fujitsu.com" , "Tomas Vondra" , "pgsql-hackers@lists.postgresql.org" , "Michael Paquier" , "Andres Freund" , "Ashutosh Bapat" , =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= , "vignesh C" Subject: Re: speed up a logical replica setup Content-Type: multipart/alternative; boundary=5065beb604d74d019b1286ec8c779361 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --5065beb604d74d019b1286ec8c779361 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 25, 2024, at 11:33 PM, Amit Kapila wrote: > On Mon, Mar 25, 2024 at 5:25=E2=80=AFPM Peter Eisentraut wrote: > > > > I have committed your version v33. I did another pass over the > > identifier and literal quoting. I added quoting for replication slot > > names, for example, even though they can only contain a restricted s= et > > of characters, but it felt better to be defensive there. > > > > I'm happy to entertain follow-up patches on some of the details like > > option naming that were still being discussed. I just wanted to get= the > > main functionality in in good time. We can fine-tune the rest over = the > > next few weeks. > > >=20 > I was looking at prior discussions on this topic to see if there are > any other open design points apart from this and noticed that the > points raised/discussed in the email [1] are also not addressed. IIRC, > the key point we discussed was that after promotion, the existing > replication objects should be removed (either optionally or always), > otherwise, it can lead to a new subscriber not being able to restart > or getting some unwarranted data. See setup_subscriber. /* * Since the publication was created before the consistent LSN, = it is * available on the subscriber when the physical replica is prom= oted. * Remove publications from the subscriber because it has no use. */ drop_publication(conn, &dbinfo[i]); -- Euler Taveira EDB https://www.enterprisedb.com/ --5065beb604d74d019b1286ec8c779361 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 25,= 2024, at 11:33 PM, Amit Kapila wrote:
On Mon, Mar 25, 2024 at 5:25=E2=80=AFPM Pete= r Eisentraut <peter@eisentrau= t.org> wrote:
>
> I have commit= ted your version v33.  I did another pass over the
&g= t; identifier and literal quoting.  I added quoting for replication= slot
> names, for example, even though they can only c= ontain a restricted set
> of characters, but it felt be= tter to be defensive there.
>
> I'm ha= ppy to entertain follow-up patches on some of the details like
=
> option naming that were still being discussed.  I just wa= nted to get the
> main functionality in in good time.&n= bsp; We can fine-tune the rest over the
> next few week= s.
>

I was looking at prio= r discussions on this topic to see if there are
any other = open design points apart from this and noticed that the
po= ints raised/discussed in the email [1] are also not addressed. IIRC,
=
the key point we discussed was that after promotion, the exis= ting
replication objects should be removed (either optiona= lly or always),
otherwise, it can lead to a new subscriber= not being able to restart
or getting some unwarranted dat= a.

See setup_subscriber.

        /*
         * Since the= publication was created before the consistent LSN, it is
=          * available on the subs= criber when the physical replica is promoted.
  =        * Remove publications from the subs= criber because it has no use.
    &nbs= p;    */
     &nbs= p;  drop_publication(conn, &dbinfo[i]);


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

--5065beb604d74d019b1286ec8c779361--