| 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 |
| 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? |