Re: Allow specifying a dbname in pg_basebackup connection string

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Jelte Fennema <me@jeltef.nl>, Jim Jones <jim.jones@uni-muenster.de>, Tristen Raab <tristen.raab@highgo.ca>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Jelte Fennema <github-tech@jeltef.nl>
Date: 2024-11-04T17:14:16Z
Lists: pgsql-hackers

Attachments

Daniel Gustafsson <daniel@yesql.se> writes:
> On 18 Sep 2023, at 14:11, Daniel Gustafsson <daniel@yesql.se> wrote:
>> Unless something sticks out in a second pass over it I will go ahead and apply
>> it.

> And applied, closing the CF entry.

I believe this patch (commit cca97ce6a) is the cause of bug #18685,
which reports that pg_basebackup fails to use ~/.pgpass for
connections [1].  Specifically, it replaced this code:

-   keywords[i] = "dbname";
-   values[i] = dbname == NULL ? "replication" : dbname;

with this code:

+       keywords[i] = "dbname";
+       values[i] = dbname;

perhaps under the illusion that dbname and connection_string can't
both be NULL.  But that ends in passing no dbname to libpq, rather
than passing "replication" which is the correct thing.  Apparently
that has no effect on the server connection, but it does break
matching of such connections to ~/.pgpass.

I think the attached will fix it, but I wonder if there are edge
cases I'm not thinking of.

			regards, tom lane

[1] https://www.postgresql.org/message-id/18685-fee2dd142b9688f1%40postgresql.org

Commits

  1. pg_basebackup, pg_receivewal: fix failure to find password in ~/.pgpass.

  2. Allow dbname in pg_basebackup/pg_receivewal connstring