RE: Have pg_basebackup write "dbname" in "primary_conninfo"? - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Have pg_basebackup write "dbname" in "primary_conninfo"?
Date
Msg-id TYCPR01MB12077971400566CF058270132F5572@TYCPR01MB12077.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Have pg_basebackup write "dbname" in "primary_conninfo"?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Have pg_basebackup write "dbname" in "primary_conninfo"?
List pgsql-hackers
Dear Horiguchi-san,

> GetConnection()@streamutil.c wants to ensure conninfo has a fallback
> database name ("replication"). However, the function seems to be
> ignoring the case where neither dbname nor connection string is given,
> which is the first case Kuroda-san raised. The second case is the
> intended behavior of the function.
>
> >    /* pg_recvlogical uses dbname only; others use connection_string only.
> */
> >    Assert(dbname == NULL || connection_string == NULL);
>
> And the function incorrectly assumes that the connection string
> requires "dbname=replication".
>
> >     * Merge the connection info inputs given in form of connection string,
> >     * options and default values (dbname=replication, replication=true,
> etc.)
>
> But the name is a pseudo database name only used by pg_hba.conf
> (maybe) , which cannot be used as an actual database name (without
> quotation marks, or unless it is actually created). The function
> should not add the fallback database name because the connection
> string for physical replication connection doesn't require the dbname
> parameter. (attached patch)

I was also missing, but the requirement was that the dbname should be included
only when the dbname option was explicitly specified [1]. Even mine and yours
cannot handle like that. Libpq function PQconnectdbParams()->pqConnectOptions2()
fills all the parameter to PGconn, at that time the information whether it is
intentionally specified or not is discarded. Then, GenerateRecoveryConfig() would
just write down all the connection parameters from PGconn, they cannot recognize.

One approach is that based on Horiguchi-san's one and initial patch, we can
avoid writing when the dbname is same as the username.

[1]: https://www.postgresql.org/message-id/CAA4eK1KH1d1J5giPMZVOtMe0iqncf1CpNwkBKoYAmXdC-kEGZg%40mail.gmail.com

Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: logical decoding and replication of sequences, take 2
Next
From: Bharath Rupireddy
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation