Subject: Re: Exit walsender before confirming remote flush in logical replication

From: Vitaly Davydov <[email-masked]>
Date: Tue, 20 Jan 2026 20:03:55 +0300

Dear Hackers,

I think, I reproduced test fails. The test fails because walsender is in
waiting state in WalSndDoneImmediate -> ereport with the following stack (see
below). It seems, it tries to send the message to the replica and flush it, but
the replica is hung.

#0  0x00007a4b37f2a037 in epoll_wait
#1  0x000056855317a2e8 in WaitEventSetWaitBlock
#2  WaitEventSetWait
#3  0x0000568552feea8e in secure_write
#4  0x0000568552ff5666 in internal_flush_buffer
#5  0x0000568552ff5966 in internal_flush
#6  socket_flush ()
#7  socket_flush ()
#8  0x00005685532ff1b3 in send_message_to_frontend (edata=<optimized out>)
#9  EmitErrorReport ()
#10 0x00005685532ff6dd in errfinish
#11 0x000056855312cc9c in WalSndDoneImmediate () at walsender.c:3625

I would propose to remove the ereport call from WalSndDoneImmediate.

With best regards,
Vitaly

On 1/19/26 15:41, Fujii Masao wrote:
> On Sun, Jan 18, 2026 at 1:20 AM Andrey Silitskiy
> <[email-masked]> wrote:
>>
>> On Jan 9, 2026 at 10:04 AM Fujii Masao
>> <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> Why do we need to send a "done" message to the receiver here?
>>> Since delivery isn't guaranteed in immediate mode, it seems of limited
>>> value.
>>
>> It seems to me that it is better to send a message in cases where it is
>> possible, so as not to raise errors on the subscriber during a clean shutdown.
>> And when this is not possible, exit the process without waiting.
>>
>>> For the immediate mode, would it make sense to log that the walsender is
>>> terminating in immediate mode and that WAL replication may be incomplete,
>>> so users can more easily understand what happened?
>>
>> Added to the latest patch.
> 
> Thanks for updating the patch!
> 
> cfbot is reporting a test failure. Could you please look into it and
> fix the issue?
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F6234
> 
> Regards,
>

---

From: Andrey Silitskiy <[email-masked]>
Date: Wed, 21 Jan 2026 22:11:47 +0700

Dear Vitaliy,
Thanks for reproducing the error.

The problem occurred during a test case with a full output buffer after
adding ereport about the termination of walsender process in immediate mode.
ereport sends message by default if replica is interested in this logging
level(WARNING level fit this description). And since the output buffer was
already full, the message could not be sent and the process could not exit.

Changed the logging level to LOG_SERVER_ONLY to exclude sending a message
to the replica during immediate shutdown.

In my environment, this error was not reproduced due to the fact that
buffers did not have time to fill up because pg_ctl stop was called
immediately after data was inserted and the buffers did not have time to
fill up and ereport did not hang.

I added a wait for sent_lsn from pg_stat_replication to stop advancing
in the test before server shutdown to give walsender time to fill output
buffers.

Regards,
Andrey Silitskiy

From a66a0bbf4a49a12fc3337b7ad15c7efd05369a58 Mon Sep 17 00:00:00 2001
From: "a.silitskiy" <[email-masked]>
Date: Fri, 28 Nov 2025 14:40:10 +0700
Subject: [PATCH v4] Introduce a new GUC 'wal_sender_shutdown_mode'.

Previously, at shutdown, walsender processes were always waiting to send all
pending data and ensure that all data is flushed in remote node. But in some cases
an unexpected wait may be unacceptable. For example, in logical replication,
apply_workers may hang on locks for some time, excluding the possibility of
sender's shutdown.

New guc allows to change shutdown mode of walsenders without changing
default behavior.

The shutdown modes are:

1) 'wait_flush' (the default). In this mode, the walsender will wait for all
WALs to be flushed on the receiver side, before exiting the process.

2) 'immediate'. In this mode, the walsender will exit without confirming the
remote flush. This may break the consistency between sender and receiver.
This mode might be useful for a system that has a high-latency network (to
reduce the amount of time for shutdown), or to allow the shutdown of
publisher even when when the subscriber's apply_worker is waiting for any
locks to be released.

Author: Andrey Silitskiy
Co-authored by: Hayato Kuroda
Discussion: https://postgr.es/m/TYAPR01MB586668E50FC2447AD7F92491F5E89%40TYAPR01MB5866.jpnprd01.prod.outlook.com
---
 doc/src/sgml/config.sgml                      |  33 +++++
 src/backend/replication/walsender.c           |  46 +++++++
 src/backend/utils/misc/guc_parameters.dat     |   7 +
 src/backend/utils/misc/guc_tables.c           |   6 +
 src/backend/utils/misc/postgresql.conf.sample |   2 +
 src/include/replication/walsender.h           |   7 +
 src/test/subscription/meson.build             |   1 +
 .../t/037_walsnd_immediate_shutdown.pl        | 121 ++++++++++++++++++
 8 files changed, 223 insertions(+)
 create mode 100644 src/test/subscription/t/037_walsnd_immediate_shutdown.pl

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0fad34da6eb..79218965cf7 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4722,6 +4722,39 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
       </listitem>
      </varlistentry>
 
+     <varlistentry id="guc-wal_sender_shutdown_mode" xreflabel="wal_sender_shutdown_mode">
+      <term><varname>wal_sender_shutdown_mode</varname> (<type>enum</type>)
+      <indexterm>
+       <primary><varname>wal_sender_shutdown_mode</varname> configuration parameter</primary>
+      </indexterm>
+      </term>
+      <listitem>
+       <para>
+        Specifies the mode in which 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>.
+        Can be set for each walsender.
+       </para>
+       <para>
+        In <literal>wait_flush</literal> mode, the walsender will wait for all
+        WALs to be flushed on the receiver side, before exiting the process. May
+        lead to unexpected lag of server shutdown.
+       </para>
+       <para>
+        In <literal>immediate</literal> mode, the walsender will exit without waiting
+        for data replication to the receiver. This may break data consistency between
+        sender and receiver after shutdown, which can be especially important in
+        case of physical replication and switch-over.
+       </para>
+       <para>
+        This mode might be useful for a system that has a high-latency network (to
+        reduce the amount of time for shutdown), or to allow the shutdown of
+        logical replication walsender even when the subscriber's apply_worker
+        is waiting for any locks to be released.
+       </para>
+      </listitem>
+     </varlistentry>
+
      <varlistentry id="guc-synchronized-standby-slots" xreflabel="synchronized_standby_slots">
       <term><varname>synchronized_standby_slots</varname> (<type>string</type>)
       <indexterm>
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 1ab09655a70..f5953ce22d0 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -130,6 +130,9 @@ int			max_wal_senders = 10;	/* the maximum number of concurrent
 									 * walsenders */
 int			wal_sender_timeout = 60 * 1000; /* maximum time to send one WAL
 											 * data message */
+
+int			wal_sender_shutdown_mode = WALSND_SHUTDOWN_MODE_WAIT_FLUSH;
+
 bool		log_replication_commands = false;
 
 /*
@@ -262,6 +265,7 @@ static void WalSndKill(int code, Datum arg);
 pg_noreturn static void WalSndShutdown(void);
 static void XLogSendPhysical(void);
 static void XLogSendLogical(void);
+pg_noreturn static void WalSndDoneImmediate(void);
 static void WalSndDone(WalSndSendDataCallback send_data);
 static void IdentifySystem(void);
 static void UploadManifest(void);
@@ -1657,6 +1661,11 @@ ProcessPendingWrites(void)
 		/* Try to flush pending output to the client */
 		if (pq_flush_if_writable() != 0)
 			WalSndShutdown();
+
+		/* If we got shut down request in immediate shutdown mode, exit the process */
+		if ((got_STOPPING || got_SIGUSR2) &&
+			 wal_sender_shutdown_mode == WALSND_SHUTDOWN_MODE_IMMEDIATE)
+			WalSndDoneImmediate();
 	}
 
 	/* reactivate latch so WalSndLoop knows to continue */
@@ -2934,6 +2943,14 @@ WalSndLoop(WalSndSendDataCallback send_data)
 		if (pq_flush_if_writable() != 0)
 			WalSndShutdown();
 
+		/*
+		 * When immediate shutdown of walsender is requested, we do not
+		 * wait for successfull sending of all data.
+		 */
+		if ((got_STOPPING || got_SIGUSR2) &&
+			 wal_sender_shutdown_mode == WALSND_SHUTDOWN_MODE_IMMEDIATE)
+			WalSndDoneImmediate();
+
 		/* If nothing remains to be sent right now ... */
 		if (WalSndCaughtUp && !pq_is_send_pending())
 		{
@@ -3582,6 +3599,35 @@ XLogSendLogical(void)
 	}
 }
 
+/*
+ * Shutdown walsender in immediate mode.
+ *
+ * NB: This should only be called when immediate shutdown of walsender
+ * was requested and shutdown signal has been received from postmaster.
+ */
+static void
+WalSndDoneImmediate()
+{
+	QueryCompletion qc;
+
+	/* Try to inform receiver that XLOG streaming is done */
+	SetQueryCompletion(&qc, CMDTAG_COPY, 0);
+	EndCommand(&qc, DestRemote, false);
+
+	/*
+	 * Note that the output buffer may be full during immediate shutdown of
+	 * walsender. If pq_flush() is called at that time, the walsender process
+	 * will be stuck. Therefore, call pq_flush_if_writable() instead. Successfull
+	 * receival of done message in immediate shutdown mode is not guaranteed.
+	 */
+	pq_flush_if_writable();
+
+	ereport(LOG_SERVER_ONLY,
+			(errmsg("walsender shutting down in immediate mode: replication may be incomplete")));
+	proc_exit(0);
+	abort();
+}
+
 /*
  * Shutdown if the sender is caught up.
  *
diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat
index 7c60b125564..96433fa6015 100644
--- a/src/backend/utils/misc/guc_parameters.dat
+++ b/src/backend/utils/misc/guc_parameters.dat
@@ -3431,6 +3431,13 @@
   check_hook => 'check_wal_segment_size',
 },
 
+{ name => 'wal_sender_shutdown_mode', type => 'enum', context => 'PGC_USERSET', group => 'REPLICATION_SENDING',
+  short_desc => 'Sets the mode in which walsender will be terminated after shutdown request.',
+  variable => 'wal_sender_shutdown_mode',
+  boot_val => 'WALSND_SHUTDOWN_MODE_WAIT_FLUSH',
+  options => 'wal_sender_shutdown_mode_options',
+},
+
 { name => 'wal_sender_timeout', type => 'int', context => 'PGC_USERSET', group => 'REPLICATION_SENDING',
   short_desc => 'Sets the maximum time to wait for WAL replication.',
   flags => 'GUC_UNIT_MS',
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 73ff6ad0a32..f2cbb0c700a 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -335,6 +335,12 @@ static const struct config_enum_entry constraint_exclusion_options[] = {
 	{NULL, 0, false}
 };
 
+static const struct config_enum_entry wal_sender_shutdown_mode_options[] = {
+	{"wait_flush", WALSND_SHUTDOWN_MODE_WAIT_FLUSH, false},
+	{"immediate", WALSND_SHUTDOWN_MODE_IMMEDIATE, false},
+	{NULL, 0, false}
+};
+
 /*
  * Although only "on", "off", "remote_apply", "remote_write", and "local" are
  * documented, we accept all the likely variants of "on" and "off".
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index dc9e2255f8a..d3c9c1d3d54 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -346,6 +346,8 @@
 #wal_sender_timeout = 60s       # in milliseconds; 0 disables
 #track_commit_timestamp = off   # collect timestamp of transaction commit
                                 # (change requires restart)
+#wal_sender_shutdown_mode = wait_flush  # walsender termination mode after
+                                # receival of shutdown request
 
 # - Primary Server -
 
diff --git a/src/include/replication/walsender.h b/src/include/replication/walsender.h
index a4df3b8e0ae..3f962ea2792 100644
--- a/src/include/replication/walsender.h
+++ b/src/include/replication/walsender.h
@@ -24,6 +24,12 @@ typedef enum
 	CRS_USE_SNAPSHOT,
 } CRSSnapshotAction;
 
+typedef enum
+{
+	WALSND_SHUTDOWN_MODE_WAIT_FLUSH = 0,
+	WALSND_SHUTDOWN_MODE_IMMEDIATE
+} WalSndShutdownMode;
+
 /* global state */
 extern PGDLLIMPORT bool am_walsender;
 extern PGDLLIMPORT bool am_cascading_walsender;
@@ -33,6 +39,7 @@ extern PGDLLIMPORT bool wake_wal_senders;
 /* user-settable parameters */
 extern PGDLLIMPORT int max_wal_senders;
 extern PGDLLIMPORT int wal_sender_timeout;
+extern PGDLLIMPORT int wal_sender_shutdown_mode;
 extern PGDLLIMPORT bool log_replication_commands;
 
 extern void InitWalSender(void);
diff --git a/src/test/subscription/meson.build b/src/test/subscription/meson.build
index a4c7dbaff59..3b9d27fba0b 100644
--- a/src/test/subscription/meson.build
+++ b/src/test/subscription/meson.build
@@ -46,6 +46,7 @@ tests += {
       't/034_temporal.pl',
       't/035_conflicts.pl',
       't/036_sequences.pl',
+      't/037_walsnd_immediate_shutdown.pl',
       't/100_bugs.pl',
     ],
   },
diff --git a/src/test/subscription/t/037_walsnd_immediate_shutdown.pl b/src/test/subscription/t/037_walsnd_immediate_shutdown.pl
new file mode 100644
index 00000000000..c991b274cd0
--- /dev/null
+++ b/src/test/subscription/t/037_walsnd_immediate_shutdown.pl
@@ -0,0 +1,121 @@
+# Copyright (c) 2026, PostgreSQL Global Development Group
+
+# Checks that publisher is able to shut down without
+# waiting for sending of all pending data to subscriber
+# with wal_sender_shutdown_mode = immediate
+
+use strict;
+use warnings FATAL => 'all';
+
+use PostgreSQL::Test::Cluster;
+use Test::More;
+
+# create publisher
+my $publisher = PostgreSQL::Test::Cluster->new('publisher');
+$publisher->init(allows_streaming => 'logical');
+# set wal_sender_shutdown_mode GUC parameter to immediate
+$publisher->append_conf('postgresql.conf',
+	"wal_sender_timeout = 0
+	 wal_sender_shutdown_mode = 'immediate'");
+$publisher->start();
+
+# create subscriber
+my $subscriber = PostgreSQL::Test::Cluster->new('subscriber');
+$subscriber->init();
+$subscriber->append_conf('postgresql.conf',
+	"wal_receiver_status_interval = 1");
+$subscriber->start();
+
+# create publication for test table
+$publisher->safe_psql('postgres', q{
+	CREATE TABLE pub_test (id int PRIMARY KEY);
+	CREATE PUBLICATION pub_all FOR TABLE pub_test;
+});
+
+# create matching table on subscriber
+$subscriber->safe_psql('postgres', q{
+	CREATE TABLE pub_test (id int PRIMARY KEY);
+});
+
+# form connection string to publisher
+my $pub_connstr = $publisher->connstr;
+
+# create the subscription on subscriber
+$subscriber->safe_psql('postgres', qq{
+	CREATE SUBSCRIPTION sub_all
+	CONNECTION '$pub_connstr'
+	PUBLICATION pub_all;
+});
+
+# wait for initial sync to finish
+$subscriber->wait_for_subscription_sync($publisher, 'sub_all');
+
+# create background psql session
+my $bpgsql = $subscriber->background_psql('postgres', on_error_stop => 0);
+
+# =============================================================================
+# Testcase start: Shutdown of publisher with empty output buffers
+
+# start transaction on subscriber to hold locks
+$bpgsql->query_safe(
+	"BEGIN; INSERT INTO pub_test VALUES (0);"
+);
+
+# run concurrent transaction on publisher and commit
+$publisher->safe_psql('postgres', 'BEGIN; INSERT INTO pub_test VALUES (0); COMMIT;');
+
+# test publisher shutdown
+$publisher->stop('fast');
+pass('successfull fast shutdown of server with empty output buffers');
+
+# Testcase end: Shutdown of publisher with empty output buffers
+# =============================================================================
+
+$bpgsql->query_safe(
+	"ABORT;"
+);
+
+# restart publisher for the next testcase
+$publisher->start();
+
+$publisher->wait_for_catchup('sub_all');
+
+# =============================================================================
+# Testcase start: Shutdown of publisher with full output buffers
+
+# lock table to make apply_worker hang
+$bpgsql->query_safe(
+	"BEGIN; LOCK TABLE pub_test IN EXCLUSIVE MODE;"
+);
+
+my $last_sent_lsn = $publisher->safe_psql('postgres', "select sent_lsn from pg_stat_replication where application_name = 'sub_all';");
+my $cur_sent_lsn;
+
+# generate big amount of wal records for locked table
+$publisher->safe_psql('postgres', 'BEGIN; INSERT INTO pub_test SELECT i from generate_series(1, 25000) s(i); COMMIT;');
+
+# waiting for walsender to fill output buffers
+my $max_attempts = $PostgreSQL::Test::Utils::timeout_default;
+while ($max_attempts-- >= 0)
+{
+	sleep 1;
+
+	$cur_sent_lsn = $publisher->safe_psql('postgres', "select sent_lsn from pg_stat_replication where application_name = 'sub_all';");
+
+	my $diff = $publisher->safe_psql('postgres', qq(
+		SELECT pg_wal_lsn_diff('$cur_sent_lsn', '$last_sent_lsn');
+	));
+
+	last if $diff == 0;
+
+	$last_sent_lsn = $cur_sent_lsn;
+}
+
+# test publisher shutdown
+$publisher->stop('fast');
+pass('successfull fast shutdown of server with full output buffers');
+
+# Testcase end: Shutdown of publisher with full output buffers
+# =============================================================================
+
+done_testing();
-- 
2.34.1

---

From: Fujii Masao <[email-masked]>
Date: Mon, 26 Jan 2026 23:08:39 +0900

> to the replica during immediate shutdown.

You changed the log level used by ereport() in WalSndDoneImmediate() to
LOG_SERVER_ONLY, but proc_exit() can still emit messages at other levels.
That could result in attempts to send additional messages to the standby.
To avoid this, should whereToSendOutput be reset, as is done
in WalSndShutdown()?

> in the test before server shutdown to give walsender time to fill output

Thanks for addressing the issue and updating the patch!

There seems also an alternative way to implement immediate shutdown of
walsenders: if wal_sender_shutdown_mode is set to immediate, the postmaster
could send SIGTERM to walsenders, just as it does to backends. In that case,
walsenders would exit without waiting for WAL replication, and the shutdown
sequence could proceed normally. With this approach, WalSndDoneImmediate()
would no longer be needed. I'm still unsure which approach is better....

One issue with the SIGTERM-based approach is that walsenders call
ereport(FATAL) on exit and may try to send the error message to the standby.
If the send buffer is full, the walsender could block in ereport(). This would
need to be addressed if we go that route.

BTW, this issue can also occur when terminating a walsender via
pg_terminate_backend() (for maintenance, etc.). If that is considered
problematic on its own, it might be better handled as a separate patch first.

Regarding the GUC name, wal_sender_shutdown seems simple and sufficient to me.
This isn't a blocker, so I'm fine with the current name for now and
revisiting it later if needed.

On the documentation, there's at least one reference to shutdown behavior
in high-availability.sgml. Since this patch changes walsender shutdown behavior,
that section should be updated as well.

+        In <literal>immediate</literal> mode, the walsender will exit
without waiting
+        for data replication to the receiver. This may break data
consistency between
+        sender and receiver after shutdown, which can be especially
important in
+        case of physical replication and switch-over.

It seems clearer to clarify the benefit of wait_flush in relation to
switchovers, rather than focusing only risks. For example:

----------------------
Specifies how a walsender process terminates after receiving a shutdown
request. Valid values are wait_flush and immediate. The default is wait_flush.
This setting can be configured per walsender.

In wait_flush mode, the walsender waits until all WAL data has been flushed on
the receiver before exiting. This helps keep the sender and receiver in sync
after shutdown, which is especially important for physical replication
switchovers. However, it can delay server shutdown.

In immediate mode, the walsender exits without waiting for WAL data to be
replicated to the receiver. This can reduce shutdown time when flushing
WAL data to the receiver would take a long time, for example on high-latency
networks or when the subscriber's apply worker is blocked waiting for locks
in logical replication.
----------------------

There's no strict rule for the ordering of parameter descriptions, but it seems
more intuitive to place wal_sender_shutdown_mode immediately after
wal_sender_timeout, rather than after track_commit_timestamp,
since the former two are more closely related. If we do that,
postgresql.conf.sample should be updated accordingly.

In postgresql.conf.sample, enum GUCs typically list their valid values in
the comment. It would be good to do the same for wal_sender_shutdown_mode.

At the top of walsender.c, there are comments describing walsender behavior,
including shutdown handling. Since this patch changes shutdown behavior,
those comments should be updated.

+typedef enum
+{

WalSndShutdownMode should be added into src/tools/pgindent/typedefs.list
for pgindent.

The comment on WalSndDoneImmediate() says it is only called after a shutdown
signal from the postmaster, but it can also be called when the checkpointer
signals walsenders to move to the stopping state (got_STOPPING = true),
which may happen earlier. So this comment seems to need to be updated.
Or, if this comment is true, WalSndDoneImmediate() should not be called under
got_STOPPING=true.

+ proc_exit(0);
+ abort();
+}

abort() call at the end of WalSndDoneImmediate() does not seem necessary.
Please see the discussion [1].

Regards,

[1] https://postgr.es/m/CAHGQGwHPX1yoixq+YB5rF4zL90TMmSEa3FpHURtqW3Jc5+=[email-masked]

Regards,

-- 
Fujii Masao

---

From: Ronan Dunklau <[email-masked]>
Date: Wed, 28 Jan 2026 08:27:28 +0000

> revisiting it later if needed.

Are we considering other approaches to this ? Having the behavior be either "wait indefinitely" or "terminate immediately" is a bit coarse I think: a timeout for the wait (maybe named wal_sender_stop_timeout ?) would allow for the same usage as this patch provides (set it to -1 for indefinite wait, 0 for immediate shutdown, or any positive value to give a chance to the walsender to catch up before we terminate it forcibly).

The problem we have as of now is when the walreceiver is indeed connected and not reaching wal_sender_timeout as it's still processing: a distinct timeout would alleviate that.

Regards,

--
Ronan Dunklau

---

From: Andrey Silitskiy <[email-masked]>
Date: Wed, 28 Jan 2026 18:27:14 +0700

Thanks for the review!

Updatedthe patchbasedonyourcomments. Regards, Andrey Silitskiy

From 948127c0edef957559c5ae6e61b81d75f394831d Mon Sep 17 00:00:00 2001
From: "a.silitskiy" <[email-masked]>
Date: Fri, 28 Nov 2025 14:40:10 +0700
Subject: [PATCH v5] Introduce a new GUC 'wal_sender_shutdown_mode'.

The shutdown modes are:

Author: Andrey Silitskiy
Co-authored by: Hayato Kuroda
Discussion: https://postgr.es/m/TYAPR01MB586668E50FC2447AD7F92491F5E89%40TYAPR01MB5866.jpnprd01.prod.outlook.com
---
 doc/src/sgml/config.sgml                      |  30 +++++
 doc/src/sgml/high-availability.sgml           |   9 +-
 src/backend/replication/walsender.c           |  52 ++++++++
 src/backend/utils/misc/guc_parameters.dat     |   7 +
 src/backend/utils/misc/guc_tables.c           |   6 +
 src/backend/utils/misc/postgresql.conf.sample |   2 +
 src/include/replication/walsender.h           |   7 +
 src/test/subscription/meson.build             |   1 +
 .../t/037_walsnd_immediate_shutdown.pl        | 121 ++++++++++++++++++
 src/tools/pgindent/typedefs.list              |   1 +
 10 files changed, 232 insertions(+), 4 deletions(-)
 create mode 100644 src/test/subscription/t/037_walsnd_immediate_shutdown.pl

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 5560b95ee60..c8c5e736cd5 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4722,6 +4722,36 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
       </listitem>
      </varlistentry>
 
+     <varlistentry id="guc-wal_sender_shutdown_mode" xreflabel="wal_sender_shutdown_mode">
+      <term><varname>wal_sender_shutdown_mode</varname> (<type>enum</type>)
+      <indexterm>
+       <primary><varname>wal_sender_shutdown_mode</varname> configuration parameter</primary>
+      </indexterm>
+      </term>
+      <listitem>
+       <para>
+        Specifies the mode in which 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>.
+        Can be set for each walsender.
+       </para>
+       <para>
+        In <literal>wait_flush</literal> mode, the walsender will wait for all
+        WAL data to be flushed on the receiver side, before exiting the process.
+        This helps to keep the sender and receiver in sync after shutdown, which is
+        especially important for physical replication switchovers. However,
+        it can delay server shutdown.
+       </para>
+       <para>
+        In <literal>immediate</literal> mode, the walsender will exit without waiting
+        for WAL data replication to the receiver. This can reduce shutdown time when
+        flushing WAL data to the receiver would take a long time, for example on
+        high-latency networks or when the subscriber's apply worker is blocked waiting
+        for locks in logical replication.
+       </para>
+      </listitem>
+     </varlistentry>
+
      <varlistentry id="guc-synchronized-standby-slots" xreflabel="synchronized_standby_slots">
       <term><varname>synchronized_standby_slots</varname> (<type>string</type>)
       <indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c3f269e0364..65e119f4851 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1190,10 +1190,11 @@ primary_slot_name = 'node_a_slot'
    </para>
 
    <para>
-    Users will stop waiting if a fast shutdown is requested.  However, as
-    when using asynchronous replication, the server will not fully
-    shutdown until all outstanding WAL records are transferred to the currently
-    connected standby servers.
+    Users will stop waiting if a fast shutdown is requested.  However, if
+    <varname>wal_sender_shutdown_mode<varname> is set to <literal>wait_flush<literal>, the
+    server will not fully shutdown until all outstanding WAL records are
+    transferred to the currently connected standby servers. This waiting
+    applies to both asynchronous and synchronous replication.
    </para>
 
    </sect3>
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index a0e6a3d200c..80cd6086908 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -35,6 +35,8 @@
  * checkpoint finishes, the postmaster sends us SIGUSR2. This instructs
  * walsender to send any outstanding WAL, including the shutdown checkpoint
  * record, wait for it to be replicated to the standby, and then exit.
+ * If wal_sender_shutdown_mode = immediate is set, walsender process will
+ * skip these steps and terminate after receival of shutdown request.
  *
  *
  * Portions Copyright (c) 2010-2026, PostgreSQL Global Development Group
@@ -130,6 +132,9 @@ int			max_wal_senders = 10;	/* the maximum number of concurrent
 									 * walsenders */
 int			wal_sender_timeout = 60 * 1000; /* maximum time to send one WAL
 											 * data message */
+
+int			wal_sender_shutdown_mode = WALSND_SHUTDOWN_MODE_WAIT_FLUSH;
+
 bool		log_replication_commands = false;
 
 /*
@@ -262,6 +267,7 @@ static void WalSndKill(int code, Datum arg);
@@ -1656,6 +1662,11 @@ ProcessPendingWrites(void)
 
 	/* reactivate latch so WalSndLoop knows to continue */
@@ -2933,6 +2944,14 @@ WalSndLoop(WalSndSendDataCallback send_data)
 		if (pq_flush_if_writable() != 0)
 			WalSndShutdown();
 
+		/*
@@ -3581,6 +3600,39 @@ XLogSendLogical(void)
 	}
 }
 
+/*
+ * Shutdown walsender in immediate mode.
+ */
+static void
+WalSndDoneImmediate()
+{
+	QueryCompletion qc;
+
+	/* Try to inform receiver that XLOG streaming is done */
+	SetQueryCompletion(&qc, CMDTAG_COPY, 0);
+	EndCommand(&qc, DestRemote, false);
+
+	/*
+	 * Note that the output buffer may be full during immediate shutdown of
+	 * walsender. If pq_flush() is called at that time, the walsender process
+	 * will be stuck. Therefore, call pq_flush_if_writable() instead. Successfull
+	 * receival of done message in immediate shutdown mode is not guaranteed.
+	 */
+	pq_flush_if_writable();
+
+	/*
+	 * Prevent ereport from attempting to send any more messages to the standby.
+	 * Otherwise it can cause process stuck if output buffers are full.
+	 */
+	if (whereToSendOutput == DestRemote)
+		whereToSendOutput = DestNone;
+
+	ereport(WARNING,
+			(errmsg("walsender shutting down in immediate mode: replication may be incomplete")));
+
+	proc_exit(0);
+}
+
 /*
  * Shutdown if the sender is caught up.
  *
diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat
index f0260e6e412..1b2267a1a15 100644
--- a/src/backend/utils/misc/guc_parameters.dat
+++ b/src/backend/utils/misc/guc_parameters.dat
@@ -3429,6 +3429,13 @@
   check_hook => 'check_wal_segment_size',
 },
 
index 13c569d8790..017c3f98b4f 100644
 
index c4f92fcdac8..29172585b93 100644
@@ -344,6 +344,8 @@
 #max_slot_wal_keep_size = -1    # in megabytes; -1 disables
 #idle_replication_slot_timeout = 0      # in seconds; 0 disables

+typedef enum
+{
 
diff --git a/src/tools/pgindent/typedefs.list b/src/tools/pgindent/typedefs.list
index ddbe4c64971..6ec7fef2f29 100644
--- a/src/tools/pgindent/typedefs.list
+++ b/src/tools/pgindent/typedefs.list
@@ -3330,6 +3330,7 @@ WalReceiverFunctionsType
 WalSnd
 WalSndCtlData
 WalSndSendDataCallback
+WalSndShutdownMode
 WalSndState
 WalSummarizerData
 WalSummaryFile
-- 
2.34.1

---

From: Andrey Silitskiy <[email-masked]>
Date: Wed, 28 Jan 2026 18:33:31 +0700

Dear Ronan,
Thanks for participating in the discussion.

On Jan 28, 2026 Ronan Dunklau <ronan(at)dunklau(dot)fr> wrote:
 > ... a timeout for the wait (maybe named wal_sender_stop_timeout ?) would
 > allow for the same usage ...

Sounds like an option.
This is also possible in the current implementation, but your option offers
a simpler interface if we do not plan to add new wallsender completion 
modes.
The naming of the parameter is also a question, because wal_sender_timeout
already exists (which also fits the name wal_sender_stop_timeout quite 
well).
The difference between these parameters may not be obvious to users.
Thoughts?

Regards,
Andrey Silitskiy

---

From: Andrey Silitskiy <[email-masked]>
Date: Mon, 2 Feb 2026 02:52:36 +0700

> Thanks for the review!
 > Updated the patch based on your comments.Fixed cfbot documentation 
error. Regards, Andrey Silitskiy

From e463bbc27c338b475a2d607ad531f2d073078faf Mon Sep 17 00:00:00 2001
From: "a.silitskiy" <[email-masked]>
Date: Fri, 28 Nov 2025 14:40:10 +0700
Subject: [PATCH v6] Introduce a new GUC 'wal_sender_shutdown_mode'.

The shutdown modes are:

Author: Andrey Silitskiy

index c3f269e0364..c4a025a0d75 100644
 
    <para>
+    <varname>wal_sender_shutdown_mode</varname> is set to <literal>wait_flush</literal>, the
 
    </sect3>
 
 /*

+		/*
 
+/*

 
 
+typedef enum
+{

---

From: Michael Paquier <[email-masked]>
Date: Mon, 2 Feb 2026 16:55:59 +0900

> +	EndCommand(&qc, DestRemote, false);

Couldn't that be potentially dangerous, particularly if
wal_sender_shutdown_mode is set to immediate, meaning that it applies
to all the WAL senders?  The WAL receiver side could be on a backend
with an older backend version than the WAL sender where this new GUC
exists.  Hence, a completion could be understood incorrectly by a WAL
receiver depending on how the receiving side is coded?  Assuming this
is merged into v19 in this shape, a receiver connecting to a newer
server would get a new bevahior compared to older versions, without
the receiver being aware of that.

I suspect that this option, as designed, is potentially a footgun that 
could surprise many users, especially as it is super aggressive in
shutting down everything on sight, unconditionally.
--
Michael

---

From: Fujii Masao <[email-masked]>
Date: Mon, 2 Feb 2026 20:58:00 +0900

> shutting down everything on sight, unconditionally.

I’m not sure this is actually problematic when terminating a walsender in
immediate mode while the subscriber is running an older PostgreSQL version.
I haven't been able to come up with any failure scenario yet. However,
if this does turn out to be an issue, it might be better to use the alternative
approach I mentioned in [1].

With that approach, even in immediate mode the walsender simply receives
SIGTERM and exits. This is not new behavior for walsenders, so even when
the subscriber is on an older version, seems it shouldn't risk breaking
the shutdown behavior that such a subscriber is expecting.

Regards,

[1] https://postgr.es/m/[email-masked]

-- 
Fujii Masao

---

From: Andrey Silitskiy <[email-masked]>
Date: Wed, 4 Feb 2026 21:03:58 +0700

On Mon, Feb 2, 2026 at 4:56 PM Michael Paquier
<michael(at)paquier(dot)xyz> wrote:
 > exists.

So far, I can't provide a scenario where the old-version receiving side is
having problems due to the behavior of immediate wal_sender_shutdown_mode.
Maybe someone else can.

Even if walsender immediate shutdown mode is set on the sender, it flushes
a done message to the receiver, as it is being done now. In the case 
when this
is not possible, it terminates in a similar way as it is currently doing
in WalSndShutdown(), the old receiver also seems to be able to handle this
case.

Regards,
Andrey Silitskiy

---

From: Ronan Dunklau <[email-masked]>
Date: Tue, 10 Feb 2026 09:15:51 +0000

> The difference between these parameters may not be obvious to users.

The naming can probably be revisited but the use case I have in mind
is the following:

- we want to bound the time it takes to perform a restart, or a stop, with walsenders setup.
- the immediate shutdown solves this problem
- however, if one were to stop the service before doing a pg_upgrade, they would
have no other choice than either disable the behaviour entirely (by switching to
wait_flush) or fail the upgrade if a logical replication slot is pending
changes. Switching to wait_flush may be acceptable in that case, but then if the walreceiver
does not catch up in time we're back to agressively stopping postgres to abort
the waiting stop process, and the upgrade entirely.

So in my mind having a timeout makes a lot more sense.

What do you think ?