Horton

Re: Exit walsender before confirming remote flush in logical replication

Fujii Masao <masao.fujii@gmail.com>

View thread
From: Fujii Masao <masao.fujii@gmail.com>
To: Andrey Silitskiy <a.silitskiy@postgrespro.ru>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "sawada.mshk@gmail.com" <sawada.mshk@gmail.com>, "michael@paquier.xyz" <michael@paquier.xyz>, "peter.eisentraut@enterprisedb.com" <peter.eisentraut@enterprisedb.com>, "dilipbalaut@gmail.com" <dilipbalaut@gmail.com>, "andres@anarazel.de" <andres@anarazel.de>, "amit.kapila16@gmail.com" <amit.kapila16@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Greg Sabino Mullane <htamfids@gmail.com>, Vitaly Davydov <v.davydov@postgrespro.ru>
Date: 2025-11-19T11:46:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add wal_sender_shutdown_timeout GUC to limit shutdown wait for replication

  2. pg_upgrade: Add --copy option

  3. Prevent possibility of panics during shutdown checkpoint.

  4. Support clean switchover.

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