Re: Have pg_basebackup write "dbname" in "primary_conninfo"?

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Have pg_basebackup write "dbname" in "primary_conninfo"?
Date: 2024-03-14 07:03:57
Message-ID: CAJpy0uAEMZsRT4_E9NNZvuw9UEQMpsk89SJ7qCYt6Q564URycg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 14, 2024 at 10:57 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > This fact makes me think that the slotsync worker might be able to
> > accept the primary_conninfo value even if there is no dbname in the
> > value. That is, if there is no dbname in the primary_conninfo, it uses
> > the username in accordance with the specs of the connection string.
> > Currently, the slotsync worker connects to the local database first
> > and then establishes the connection to the primary server. But if we
> > can reverse the two steps, it can get the dbname that has actually
> > been used to establish the remote connection and use it for the local
> > connection too. That way, the primary_conninfo generated by
> > pg_basebackup could work even without the patch. For example, if the
> > OS user executing pg_basebackup is 'postgres', the slotsync worker
> > would connect to the postgres database. Given the 'postgres' database
> > is created by default and 'postgres' OS user is used in common, I
> > guess it could cover many cases in practice actually.
> >
>
> I think this is worth investigating but I suspect that in most cases
> users will end up using a replication connection without specifying
> the user name and we may not be able to give a meaningful error
> message when slotsync worker won't be able to connect. The same will
> be true even when the dbname same as the username would be used.
>

I attempted the change as suggested by Swada-San. Attached the PoC
patch .For it to work, I have to expose a new get api in libpq-fe
which gets dbname from stream-connection. Please have a look.

Without this PoC patch, the errors in slot-sync worker:

-----------------
a) If dbname is missing:
[1230932] LOG: slot sync worker started
[1230932] ERROR: slot synchronization requires dbname to be specified
in primary_conninfo

b) If specified db does not exist
[1230913] LOG: slot sync worker started
[1230913] FATAL: database "postgres1" does not exist
-----------------

Now with this patch:
-----------------
a) If the dbname same as user does not exist:
[1232473] LOG: slot sync worker started
[1232473] ERROR: could not connect to the primary server: connection
to server at "127.0.0.1", port 5433 failed: FATAL: database
"bckp_user" does not exist

b) If user itself is removed from primary_conninfo, libpq takes user
who has authenticated the system by default and gives error if db of
same name does not exist
ERROR: could not connect to the primary server: connection to server
at "127.0.0.1", port 5433 failed: FATAL: database "shveta" does not
exist
-----------------

The errors in second case look slightly confusing to me.

thanks
Shveta

Attachment Content-Type Size
v1-0001-Use-user-as-dbname-for-slot-sync.patch application/octet-stream 10.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-03-14 07:04:50 Re: Using the %m printf format more
Previous Message Michael Paquier 2024-03-14 07:00:44 Re: Add basic tests for the low-level backup method.