diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2024-11-04 14:36:04 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2024-11-04 14:36:11 -0500 |
| commit | b1008c1f01ff5cd35d2394bde2532c40781e696f (patch) | |
| tree | 244d9fe5016f8e6757c932ade1171ecdbf6d911a /src/backend/executor/execMain.c | |
| parent | 32d07a000ffa9f5f6fb418a23d1bced22f20481d (diff) | |
| download | postgresql-b1008c1f01ff5cd35d2394bde2532c40781e696f.tar.gz postgresql-b1008c1f01ff5cd35d2394bde2532c40781e696f.zip | |
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
Diffstat (limited to 'src/backend/executor/execMain.c')
0 files changed, 0 insertions, 0 deletions