Do quoting more carefully in replication commands

Hi,

On Fri, 12 Jun 2026 at 23:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The security team received a report that pg_recvlogical was
careless about quoting --option arguments that are passed
into the START_REPLICATION command given to the server. In
principle this'd allow an attacker to inject unwanted stuff
into START_REPLICATION's options. However, we found it really
hard to envision a situation where somebody would be passing
strings obtained from untrustworthy sources to pg_recvlogical,
especially given that anything to do with replication already
requires pretty high privilege. So we're electing to treat this
as a garden-variety bug rather than one requiring the CVE process.

Looking around revealed other places also being sloppy about
quoting strings inserted into replication commands, but the same
who-would-do-that argument applies to them too. So here is a
patch that tries to clean all that up.

(I envision back-patching this all the way, but have not yet
looked at whether the back branches will require adjustments.)

Thanks for the patch!

I looked at the patch and big +1 on handling quoting wherever
feasible rather than depending on some parent or child function to do that.

Not only does the patch fix quoting, it also fixes some
workflows (it is on the right side, so I think adding a test
is optional though some ERROR / behaviour would change,
for example some earlier "Syntax error" would fall through
the whole function).

$ pg_receivewal -D wal --slot=999 --no-sync
pg_receivewal: error: could not send replication command
"READ_REPLICATION_SLOT": ERROR: syntax error
pg_receivewal: disconnected; waiting 5 seconds to try again
pg_receivewal: error: could not send replication command
"READ_REPLICATION_SLOT": ERROR: syntax error
[loops]

The above works fine post the patch. Even for libpqwalreceiver
issue when publication_names containing a backslash, as mentioned
in your patch commit, earlier subscription used to be permanently stuck due
to that addition of E.

All in all, I did not find any issues with the patch, lgtm.

Regards,
Ayush

On 2026-Jun-12, Tom Lane wrote:

(I envision back-patching this all the way, but have not yet
looked at whether the back branches will require adjustments.)

In a quick skim, I wondered about this bit:

+ * Caution: this quoting logic is sufficient for identifiers and literals
+ * in the replication grammar, but not always in regular SQL.  Specifically,
+ * it'd fail for a string literal if standard_conforming_strings is off.

... given that standard_conforming_strings can no longer be off in 19.
The backpatched version should surely still have this, just in case, but
in 19 it's probably not needed.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php

Ayush Tiwari <ayushtiwari.slg01@gmail.com> writes:

All in all, I did not find any issues with the patch, lgtm.

Pushed, thanks for reviewing.

regards, tom lane