Fix START_REPLICATION failure with publication names containing backslashes

From: vignesh C <vignesh21(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Fix START_REPLICATION failure with publication names containing backslashes
Date: 2025-12-03 09:50:31
Message-ID: CALDaNm18fTpUg+16y+w0Tjzwuwb=F11P7yF7TCXnmnJofWxbdg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While reviewing another patch, I noticed that START_REPLICATION fails
to parse publication names that contain backslash characters (e.g. \0,
\n), even though such names are perfectly valid when used with CREATE
PUBLICATION. This can be reproduced with the following:
CREATE PUBLICATION "regress_pub_\0\n";
CREATE SUBSCRIPTION regress_sub CONNECTION 'dbname=postgres
host=localhost port=5432' PUBLICATION "regress_pub_\0\n";

CREATE PUBLICATION allows quoted identifiers that may include
backslashes. However, when the subscriber sends such a publication
name back to the walsender as part of START_REPLICATION, the
replication grammar rejects it and throws a syntax error. This happens
because the publication name is passed through escape string
processing before being sent, even though the replication grammar does
not accept escape string forms. The attached patch removes the
unnecessary escape-string handling and passes the publication name as
it is. Replication grammar does not require escape string processing
here, and sending the raw identifier ensures consistent behaviour
between CREATE PUBLICATION and START_REPLICATION.

Regards,
Vignesh

Attachment Content-Type Size
0001-Fix-START_REPLICATION-failure-when-publication-names.patch application/octet-stream 4.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Orlov 2025-12-03 09:54:23 Re: POC: make mxidoff 64 bits
Previous Message David Geier 2025-12-03 09:50:15 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?