pg_basebackup, pg_receivewal: fix failure to find password in ~/.pgpass.
commite2a912909308041d629f1e62ea84c76d179674b1
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 4 Nov 2024 19:36:04 +0000 (4 14:36 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 4 Nov 2024 19:36:04 +0000 (4 14:36 -0500)
treefa0564694d7defc6cc895e9c9275f694bd96d536
parente367114429e09696fce01dd6f256e58a2c858734
pg_basebackup, pg_receivewal: fix failure to find password in ~/.pgpass.

Sloppy refactoring in commit cca97ce6a caused these programs
to pass dbname = NULL to libpq if there was no "--dbname" switch
on the command line, where before "replication" would be passed.
This didn't break things completely, because the source server doesn't
care about the dbname specified for a physical replication connection.
However, it did cause libpq to fail to match a ~/.pgpass entry that
has "replication" in the dbname field.  Restore the previous behavior
of passing "replication".

Also, closer inspection shows that if you do specify a dbname
in the connection string, that is what will be matched to ~/.pgpass,
not "replication".  This was the pre-existing behavior so we should
not change it, but the SGML docs were pretty misleading about it.
Improve that.

Per bug #18685 from Toshi Harada.  Back-patch to v17 where the
error crept in.

Discussion: https://postgr.es/m/18685-fee2dd142b9688f1@postgresql.org
Discussion: https://postgr.es/m/2702546.1730740456@sss.pgh.pa.us
doc/src/sgml/ref/pg_basebackup.sgml
doc/src/sgml/ref/pg_receivewal.sgml
src/bin/pg_basebackup/streamutil.c