Allow specifying a dbname in pg_basebackup connection string

From: Jelte Fennema <postgres(at)jeltef(dot)nl>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Allow specifying a dbname in pg_basebackup connection string
Date: 2023-07-03 12:22:40
Message-ID: CAGECzQTw-dZkVT_RELRzfWRzY714-VaTjoBATYfZq93R8C-auA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v1-0001-Allow-specifying-a-dbname-in-pg_basebackup-connec.patch application/octet-stream 3.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema 2023-07-03 12:33:55 Re: Deleting prepared statements from libpq.
Previous Message jian he 2023-07-03 12:22:04 Re: [PGdocs] fix description for handling pf non-ASCII characters