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 1rnJRO-00Cdl3-PM for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Mar 2024 14:30:47 +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 1rnJRM-00DzT3-UN for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Mar 2024 14:30:45 +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 1rnJRL-00DzSs-Sb for pgsql-hackers@lists.postgresql.org; Thu, 21 Mar 2024 14:30:45 +0000 Received: from wfout8-smtp.messagingengine.com ([64.147.123.151]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnJRI-005jsU-6G for pgsql-hackers@lists.postgresql.org; Thu, 21 Mar 2024 14:30:43 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.west.internal (Postfix) with ESMTP id 69ADC1C000C4; Thu, 21 Mar 2024 10:30:36 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute2.internal (MEProxy); Thu, 21 Mar 2024 10:30:37 -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=1711031435; x=1711117835; bh=543Wj22la7 4kC5DAkfTJQ6GMJawBwfQNmebjn4k0tuI=; b=OOi+2PMDlv2b5oiAG+xFa2W0SC jtVV05Xwcb4Ji3cve9/b7SnFnn+VGd+pfo0oypfQ0IJzhR/jZpSzKWNX+UYt4Ny4 PNjm7azdNF9Tq7IkiIRKOrf8DxJDNZlnt998Lr0St9wVpYyMgQOtapS6E6Hqbt1w 4k2D6JCFtkzJvAHs9sqNtSiN26vljM81tyQcteM+ss9sLPjGD3583Wd5lP8Xm1rv ll2FtL70feWhFIT3hpzIWQduxUzSmtzRAouaTlLMk7gNE3zSbCYLvG3pe6JwY3wC ApJu/NmuP/8asoewGiYQjDn2dYT3Y0s0HZOnv/E4bcjwPEAqqKQdB7LYsxPg== 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=1711031435; x=1711117835; bh=543Wj22la74kC5DAkfTJQ6GMJawB wfQNmebjn4k0tuI=; b=TKGOJ+mEcnih+Kwz3oRcgd5c93R40iD1JuN2Is5SKsy0 2zH/KGiClih7MHqZXmO3xgyuZbfM2pZnfFRxO3DdNv2+3bJdf4Z3EzkqPx21tFgo DjPL+XZkzYgsAQU0PTu3lE9jNE5jvPxECKhaZ2yj7Z+7q+GLs1/PUiPzPrd5/OuQ CWt4oNntDo+DuudfKfJ19eUPUsut9M0URXSwxnDJ1VleAFVbnW/IRJ8i6bDYcRGX HJ4c7Pw7lzZUk/TY1VlvQOP+rkIT21xVJtcp7dBojiTChks6qsiwAaPNU/lOe0rP S3xOzbXLiDZKhNgrschXbuOhuYgx+aXX4zhHnhZomw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrleejgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreertdenucfhrhhomhepfdfguhhl vghrucfvrghvvghirhgrfdcuoegvuhhlvghrsegvuhhlvghrthhordgtohhmqeenucggtf frrghtthgvrhhnpefgffejvdeivdekvdeivdetudeikeduieevtdfhhfduvdetgeelteei ffekgefhvdenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghulhgvrhesvghu lhgvrhhtohdrtghomh X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1210A15A0092; Thu, 21 Mar 2024 10:30:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-332-gdeb4194079-fm-20240319.002-gdeb41940 MIME-Version: 1.0 Message-Id: <07a0f7d7-8ec9-4649-8bcb-610fd430eebd@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> <60b45b8a-3047-4a21-ba2a-ddb15daa638f@eisentraut.org> Date: Thu, 21 Mar 2024 11:30:05 -0300 From: "Euler Taveira" To: "vignesh C" , "Peter Eisentraut" Cc: "Amit Kapila" , "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?= Subject: Re: speed up a logical replica setup Content-Type: multipart/alternative; boundary=b645710a94464af9bf986aba8aaa5c2d List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --b645710a94464af9bf986aba8aaa5c2d Content-Type: text/plain On Thu, Mar 21, 2024, at 10:33 AM, vignesh C wrote: > If we commit this we might not be able to change the way the option > behaves once the customers starts using it. How about removing these > options in the first version and adding it in the next version after > more discussion. We don't need to redesign this one if we want to add a format string in a next version. A long time ago, pg_dump started to accept pattern for tables without breaking or deprecating the -t option. If you have 100 databases and you don't want to specify the options or use a script to generate it for you, you also have the option to let pg_createsubscriber generate the object names for you. Per my experience, it will be a rare case. > Currently dry-run will do the check and might fail on identifying a > few failures like after checking subscriber configurations. Then the > user will have to correct the configuration and re-run then fix the > next set of failures. Whereas the suggest-config will display all the > optimal configuration for both the primary and the standby in a single > shot. This is not a must in the first version, it can be done as a > subsequent enhancement. Do you meant publisher, right? Per order, check_subscriber is done before check_publisher and it checks all settings on the subscriber before exiting. In v30, I changed the way it provides the required settings. In a previous version, it fails when it found a wrong setting; the current version, check all settings from that server before providing a suitable error. pg_createsubscriber: checking settings on publisher pg_createsubscriber: primary has replication slot "physical_slot" pg_createsubscriber: error: publisher requires wal_level >= logical pg_createsubscriber: error: publisher requires 2 replication slots, but only 0 remain pg_createsubscriber: hint: Consider increasing max_replication_slots to at least 3. pg_createsubscriber: error: publisher requires 2 wal sender processes, but only 0 remain pg_createsubscriber: hint: Consider increasing max_wal_senders to at least 3. If you have such an error, you will fix them all and rerun using dry run mode again to verify everything is ok. I don't have a strong preference about it. It can be changed easily (unifying the check functions or providing a return for each of the check functions). -- Euler Taveira EDB https://www.enterprisedb.com/ --b645710a94464af9bf986aba8aaa5c2d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Mar 21,= 2024, at 10:33 AM, vignesh C wrote:
If we commit this we might not be able to chan= ge the way the option
behaves once the customers starts us= ing it. How about removing these
options in the first vers= ion and adding it in the next version after
more discussio= n.

We don't need to redesign t= his one if we want to add a format string in a next
versio= n. A long time ago, pg_dump started to accept pattern for tables without=
breaking or deprecating the -t option. If you have 100 da= tabases and you don't
want to specify the options or use a= script to generate it for you, you also
have the option t= o let pg_createsubscriber generate the object names for you.
Per my experience, it will be a rare case.

Currently dry-run will= do the check and might fail on identifying a
few failures= like after checking subscriber configurations. Then the
u= ser will have to correct the configuration and re-run then fix the
next set of failures. Whereas the suggest-config will display a= ll the
optimal configuration for both the primary and the = standby in a single
shot. This is not a must in the first = version, it can be done as a
subsequent enhancement.

Do you meant publisher, right? Per = order, check_subscriber is done before
check_publisher and= it checks all settings on the subscriber before exiting. In
v30, I changed the way it provides the required settings. In a previo= us version,
it fails when it found a wrong setting; the cu= rrent version, check all settings
from that server before = providing a suitable error.

pg_createsubscr= iber: checking settings on publisher
pg_createsubscriber: = primary has replication slot "physical_slot"
pg_createsubs= criber: error: publisher requires wal_level >=3D logical
pg_createsubscriber: error: publisher requires 2 replication slots, bu= t only 0 remain
pg_createsubscriber: hint: Consider increa= sing max_replication_slots to at least 3.
pg_createsubscri= ber: error: publisher requires 2 wal sender processes, but only 0 remain=
pg_createsubscriber: hint: Consider increasing max_wal_se= nders to at least 3.

If you have such an er= ror, you will fix them all and rerun using dry run mode
ag= ain to verify everything is ok. I don't have a strong preference about i= t. It
can be changed easily (unifying the check functions = or providing a return for
each of the check functions).


--
Euler Taveira

=
--b645710a94464af9bf986aba8aaa5c2d--