MIME-Version: 1.0
References: <CA+TgmoYfagyp5AvKMfGpRUgXNJZ0ymuqiWTzOc2tV_ZMM0UkCA@mail.gmail.com>
 <TYCPR01MB1207777150173002564A753B8F5502@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <CA+TgmoaLRCcCeY3_n7h0rw-r-UfJt_GiFZiJQ1pFZ-iQNUozug@mail.gmail.com>
 <20240221.120424.79274783106518358.horikyota.ntt@gmail.com>
 <CAA4eK1Jh=V38dRV059wdbacT9TkQ0oWGcqDfo5V4X2shvKykfA@mail.gmail.com>
 <TYCPR01MB1207779B65625AAEC975B5EC0F5592@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <TYCPR01MB12077B81FCAFDFE104DEEE7BAF5592@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <CAA4eK1L+39988Rzq4hD0h1y+s0234PH3G-u7NbUmfwE438mbGQ@mail.gmail.com> <CALDaNm0tr-t_L+anY1+qseAajpdE1H-cFQzcPzXoRJWUjvOdXg@mail.gmail.com>
In-Reply-To: <CALDaNm0tr-t_L+anY1+qseAajpdE1H-cFQzcPzXoRJWUjvOdXg@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Wed, 13 Mar 2024 16:58:09 +0530
Message-ID: <CAA4eK1+bbMg+Zbp=r6yCSqb3EPHcyeg-0gHkdUWD_w-d5+2sGw@mail.gmail.com>
Subject: Re: Have pg_basebackup write "dbname" in "primary_conninfo"?
To: vignesh C <vignesh21@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, 
	"robertmhaas@gmail.com" <robertmhaas@gmail.com>, "barwick@gmail.com" <barwick@gmail.com>, 
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1%2BbbMg%2BZbp%3Dr6yCSqb3EPHcyeg-0gHkdUWD_w-d5%2B2sGw%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 12, 2024 at 5:13=E2=80=AFPM vignesh C <vignesh21@gmail.com> wro=
te:
>
> On Mon, 11 Mar 2024 at 17:16, Amit Kapila <amit.kapila16@gmail.com> wrote=
:
> >
> > On Tue, Feb 27, 2024 at 2:07=E2=80=AFPM Hayato Kuroda (Fujitsu)
> > <kuroda.hayato@fujitsu.com> wrote:
> > >
> > > > PSA the patch for implementing it. It is basically same as Ian's on=
e.
> > > > However, this patch still cannot satisfy the condition 3).
> > > >
> > > > `pg_basebackup -D data_N2 -d "user=3Dpostgres" -R`
> > > > -> dbname would not be appeared in primary_conninfo.
> > > >
> > > > This is because `if (connection_string)` case in GetConnection() ex=
plicy override
> > > > a dbname to "replication". I've tried to add a dummy entry {"dbname=
", NULL} pair
> > > > before the overriding, but it is no-op. Because The replacement of =
the dbname in
> > > > pqConnectOptions2() would be done only for the valid (=3Dlastly spe=
cified)
> > > > connection options.
> > >
> > > Oh, this patch missed the straightforward case:
> > >
> > > pg_basebackup -D data_N2 -d "user=3Dpostgres dbname=3Dreplication" -R
> > > -> dbname would not be appeared in primary_conninfo.
> > >
> > > So I think it cannot be applied as-is. Sorry for sharing the bad item=
.
> > >
> >
> > Can you please share the patch that can be considered for review?
>
> Here is a patch with few changes: a) Removed the version check based
> on discussion from [1] b) updated the documentation.
> I have tested various scenarios with the attached patch, the dbname
> that is written in postgresql.auto.conf for each of the cases with
> pg_basebackup is given below:
> 1) ./pg_basebackup -U vignesh -R
> -> primary_conninfo =3D "dbname=3Dvignesh" (In this case primary_conninfo
> will have dbname as username specified)
> 2) ./pg_basebackup -D data -R
> -> primary_conninfo =3D "dbname=3Dvignesh" (In this case primary_conninfo
> will have the dbname as username (which is the same as the OS user
> while setting defaults))
> 3) ./pg_basebackup -d "user=3Dvignesh"  -D data -R
> -> primary_conninfo =3D "dbname=3Dreplication"  (In this case
> primary_conninfo will have dbname as replication which is the default
> value from GetConnection as connection string is specified)
> 4) ./pg_basebackup -d "user=3Dvignesh dbname=3Dpostgres"  -D data -R
> -> primary_conninfo =3D "dbname=3Dpostgres" (In this case primary_conninf=
o
> will have the dbname as the dbname specified)
> 5) ./pg_basebackup -d ""  -D data -R
> -> primary_conninfo =3D "dbname=3Dreplication" (In this case
> primary_conninfo will have dbname as replication which is the default
> value from GetConnection as connection string is specified)
>
> I have mentioned the reasons as to why dbname is being set to
> replication or username in each of the cases.
>

IIUC, the dbname is already allowed in connstring for pg_basebackup by
commit cca97ce6a6 and with this patch we are just writing it in
postgresql.auto.conf if -R option is used to write recovery info. This
will help slot syncworker to automatically connect with database
without user manually specifying the dbname and replication
connection, the same will still be ignored. I don't see any problem
with this. Does anyone else see any problem?

The <filename>postgresql.auto.conf</filename> file will record the connecti=
on
         settings and, if specified, the replication slot
         that <application>pg_basebackup</application> is using, so that
-        streaming replication will use the same settings later on.
+        a) synchronization of logical replication slots on the primary to =
the
+        hot_standby from <link linkend=3D"pg-sync-replication-slots">
+        <function>pg_sync_replication_slots</function></link> or slot
sync worker
+        and b) streaming replication will use the same settings later on.

We can simply modify the last line as: ".. streaming replication or
logical replication slots synchronization will use the same settings
later on." Additionally, you can give a link reference to [1].

[1] - https://www.postgresql.org/docs/devel/logicaldecoding-explanation.htm=
l#LOGICALDECODING-REPLICATION-SLOTS-SYNCHRONIZATION
--=20
With Regards,
Amit Kapila.