Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

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

Browse pgsql-hackers by date

  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