Feedback-ID: ie0a040ee:Fastmail
Message-ID: <60b45b8a-3047-4a21-ba2a-ddb15daa638f@eisentraut.org>
Date: Thu, 21 Mar 2024 13:32:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: speed up a logical replica setup
Content-Language: en-US
To: vignesh C <vignesh21@gmail.com>, Euler Taveira <euler@eulerto.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
 Shlok Kyal <shlok.kyal.oss@gmail.com>,
 "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>,
 Tomas Vondra <tomas.vondra@enterprisedb.com>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello@gmail.com>
References: <9a9c7e65-c47b-4400-a63e-ac6169c0860e@app.fastmail.com>
 <TYCPR01MB12077CD333376B53F9CAE7AC0F5562@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <e390e35e-508e-4eb8-92e4-e6b066407a41@app.fastmail.com>
 <TYCPR01MB12077121263EFF7680486B635F5212@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <40595e73-c7e1-463a-b8be-49792e870007@app.fastmail.com>
 <6423dfeb-a729-45d3-b71e-7bf1b3adb0c9@enterprisedb.com>
 <TYCPR01MB12077DE77454D68E959E85E35F5272@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <e8564096-3c4f-4990-ac7d-ba089739b878@app.fastmail.com>
 <CANhcyEW6-dH28gLbFc5XpDTJ6JPizU+t5g-aKUWJBf5W_Zriqw@mail.gmail.com>
 <2f0b73f3-e7c0-4e95-9712-1993442a6b64@app.fastmail.com>
 <CAA4eK1JtnzqYNQ_S+mj_XsPfgk7szxegKiVQq4-8fY1wUcUnpg@mail.gmail.com>
 <34637e7f-0330-420d-8f45-1d022962d2fe@app.fastmail.com>
 <7a970912-0b77-4942-84f7-2c9ca0bc05a5@eisentraut.org>
 <d546c4bb-92d1-4e2d-898f-48234b12ed25@app.fastmail.com>
 <CALDaNm1Dg5tDRmaabk+ZND4WF17NrNq52WZxCE+90-PGz5trQQ@mail.gmail.com>
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CALDaNm1Dg5tDRmaabk+ZND4WF17NrNq52WZxCE+90-PGz5trQQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/60b45b8a-3047-4a21-ba2a-ddb15daa638f%40eisentraut.org>
Precedence: bulk

On 21.03.24 12:35, vignesh C wrote:
> Here are a few suggestions:
> 1) I felt displaying the server log to the console is not a good idea,
> I prefer this to be logged. There were similar comments from
> Kuroda-san at [1], Peter at [2]. The number of lines will increase
> based on the log level set. If you don't want to use pg_upgrade style,
> how about exposing the log file option and logging it to the specified
> log file.

Let's leave that for the next version.  We need to wrap things up for 
this release.

> 2) Currently for publication, replication-slot and subscription, we
> will have to specify these options based on the number of databases.
> Here if we have 100 databases we will have to specify these options
> 100 times, it might not be user friendly. How about something like
> what Tomas had proposed at [3] and  Amit proposed at [4]. It will be
> better if the user has to just specify publication, replication slot
> and subscription options only one time.

Same.  Designing, implementing, discussing, and testing this cannot be 
done in the time remaining.

> +       /* Number of object names must match number of databases */
> +       if (num_pubs > 0 && num_pubs != num_dbs)
> +       {
> +               pg_log_error("wrong number of publication names");
> +               pg_log_error_hint("Number of publication names (%d)
> must match number of database names (%d).",
> +                                                 num_pubs, num_dbs);
> +               exit(1);
> +       }
> 
> 3) Can we have an option similar to dry-run which will display the
> configurations required in the primary and standby node something
> like:
> pg_createsubscriber -D data_N2/ -P "port=5431 user=postgres"  -p 9999
> -s /home/vignesh/postgres/inst/bin/ -U postgres -d db1 -d db2
> --suggest-config
> Suggested optimal configurations in the primary:
> --------------------------------------
> wallevel = logical
> max_replication_slots = 3
> max_wal_senders = 3
> ...
> Suggested optimal configurations in the standby:
> --------------------------------------
> max_replication_slots = 3
> max_wal_senders = 3
> ...

How would this be different from what --dry-run does now?