| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |
| Date: | 2025-11-18 15:59:00 |
| Message-ID: | CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
In logical replication, any GUC settings specified in the CONNECTION clause of
CREATE SUBSCRIPTION are currently ignored. For example:
CREATE SUBSCRIPTION mysub
CONNECTION 'options=''-c wal_sender_timeout=1000'''
PUBLICATION ...
The wal_sender_timeout value here has no effect.
This is inconvenient when different logical replication walsenders need
different settings - e.g., a small wal_sender_timeout for walsender
connecting to a nearby subscriber and a larger one for walsender
connecting to a distant subscriber. Right now, it's not easy for users
to control such per-connection behavior.
The reason of thid limitation is that libpqrcv_connect() always overwrites
the options connection parameter as follows:
keys[++i] = "options";
vals[i] = "-c datestyle=ISO -c intervalstyle=postgres -c
extra_float_digits=3";
This wipes out any user-specified GUCs in the CONNECTION string.
Physical replication does not have this problem because it does not overwrite
options, so GUCs in primary_conninfo are honored.
To remove this restriction, how about switching to issuing SET commands for
datestyle, intervalstyle, and extra_float_digits after the connection
is established,
similar to what postgres_fdw does, instead of forcing them into options?
That would allow user-specified GUC settings in CREATE SUBSCRIPTION to
take effect.
This overwrite behavior was introduced in commit f3d4019da5d and chosen mainly
to avoid extra network round trips according to the discussion [1].
While SET commands would add a round trip, it only happens at
connection startup,
which is infrequent - so the overhead seems negligible.
Thoughts?
Regards,
[1] https://postgr.es/m/CAFF0-CF=D7pc6st-3A9f1JnOt0qmc+BcBPVzD6fLYisKyAjkGA@mail.gmail.com
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-11-18 16:00:05 | Re: regarding statistics retaining with 18 Upgrade |
| Previous Message | Peter Eisentraut | 2025-11-18 15:54:32 | Re: Consistently use the XLogRecPtrIsInvalid() macro |