On Tue, Nov 18, 2025 at 7:32 PM Andrey Silitskiy
<a.silitskiy@postgrespro.ru> wrote:
>
> Dear pgsql-hackers,
>
> I am also interested in solving this problem, so I suggest a patch which
> is based on Hayato's work shared earlier.
+1
Thanks for the patch!
+{ name => 'logical_wal_sender_shutdown_mode', type => 'enum', context
=> 'PGC_SIGHUP', group => 'REPLICATION_SENDING',
How about using PGC_USERSET instead of PGC_SIGHUP, similar to
wal_sender_timeout?
That would allow setting logical_wal_sender_shutdown_mode per walsender
by assigning it to the logical replication user on the publisher and specifying
that user in the CONNECTION clause of CREATE SUBSCRIPTION command. For example:
# publisher
=# ALTER ROLE testuser SET logical_wal_sender_shutdown_mode TO 'immediate';
# subscriber
=# CREATE SUBSCRIPTION ... CONNECTION '... user=testuser' ...;
Even if the publisher's postgresql.conf sets logical_wal_sender_shutdown_mode to
'wait_flush', the per-role setting would take effect for that connection.
This gives users per-connection control, just like with parameters such as
wal_sender_timeout.
Also if the patch I proposed in [1] is committed, the same per-connection
control could be done directly via CREATE SUBSCRIPTION:
# subscriber
=# CREATE SUBSCRIPTOIN ... CONNECTION '... options=''-c
logical_wal_sender_shutdown_mode=immediate'''
+ Specifies the mode in which logical walsender process will terminate
+ after receival of shutdown request. Valid values are
+ <literal>wait_flush</literal> and <literal>immediate</literal>.
+ Default value is <literal>wait_flush</literal>.
Shouldn't physical replication walsenders also honor this parameter?
For example, the immediate mode seems useful for physical walsenders connected
from a very remote standby (e.g., DR site). Thought?
Regards,
[1] https://postgr.es/m/CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com
--
Fujii Masao
