Normally it doesn't really matter which dbname is used in the connection string that pg_basebackup and other physical replication CLI tools use. The reason being, that physical replication does not work at the database level, but instead at the server level. So you will always get the data for all databases.
However, when there's a proxy, such as PgBouncer, in between the client and the server, then it might very well matter. Because this proxy might want to route the connection to a different server depending on the dbname parameter in the startup packet. This patch changes the creation of the connection string key value pairs, so that the following command will actually include dbname=postgres in the startup packet to the server: pg_basebackup --dbname 'dbname=postgres port=6432' -D dump This also applies to other physical replication CLI tools like pg_receivewal. To address the security issue described in CVE-2016-5424 it now only passes expand_dbname=true when the tool did not receive a connection_string argument. I tested that the change worked on this PgBouncer PR of mine: https://github.com/pgbouncer/pgbouncer/pull/876
v1-0001-Allow-specifying-a-dbname-in-pg_basebackup-connec.patch
Description: Binary data
