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
- fix-pg_basebackup-pgpass-matching.patch (text/x-diff) patch
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
-
pg_basebackup, pg_receivewal: fix failure to find password in ~/.pgpass.
- b1008c1f01ff 18.0 landed
- e2a912909308 17.1 landed
-
Allow dbname in pg_basebackup/pg_receivewal connstring
- cca97ce6a665 17.0 landed