Re: Exit walsender before confirming remote flush in logical replication

> On Apr 23, 2026, at 12:51, Fujii Masao <masao.fujii@gmail.com> wrote:
> 
> On Wed, Apr 22, 2026 at 3:32 AM Fujii Masao <masao.fujii@gmail.com> wrote:
>> Therefore, since replacing pq_flush() with pq_flush_if_writable() seems to
>> change behavior only in a limited and acceptable way, I'm thinking to create
>> the patch doing that replacement.
> 
> On second thought, replacing pq_flush() with pq_flush_if_writable() is not
> sufficient. EndCommand(), which WalSndDone() calls before pq_flush(), can also
> block when the send buffer is full. That happens because EndCommand() uses
> pq_putmessage() rather than pq_putmessage_noblock().
> 
> Also, replacing pq_flush() with pq_flush_if_writable() would cause walsender to
> give up sending pending messages, including CommandComplete, even before
> wal_sender_shutdown_timeout expires. That seems a bit odd. I think it is better
> for walsender to continue honoring wal_sender_shutdown_timeout while attempting
> to send the final CommandComplete message.
> 
> I've attached a patch that addresses both issues. For the first, it introduces
> EndCommandExtended(), which allows CommandComplete to be queued with
> pq_putmessage_noblock(). For the second, it updates WalSndDone() to use
> ProcessPendingWrites() instead of pq_flush(), so the walsender write loop can
> continue processing replies and checking replication and shutdown timeouts
> while pending output is being flushed.
> 
> Thoughts?
> 
> Regards,
> 
> -- 
> Fujii Masao
> <v1-0001-Avoid-blocking-indefinitely-while-finishing-walse.patch>

```
-		EndCommand(&qc, DestRemote, false);
-		pq_flush();
+		EndCommandExtended(&qc, DestRemote, false, true);
+		shutdown_stream_done_queued = true;
+
+		/*
+		 * Don't call pq_flush() here. It can block indefinitely waiting for
+		 * the socket to become writeable, which would prevent
+		 * wal_sender_shutdown_timeout from being enforced. Use the regular
+		 * walsender non-blocking flush path so shutdown and replication
+		 * timeouts continue to be checked while waiting for the send buffer
+		 * to drain.
+		 */
+		ProcessPendingWrites();
```

I think adding EndCommandExtended() with a “nonblock” parameter is good. However, I have a suspicion replacing pg_flush with ProcessPendingWrites().

ProcessPendingWrites() calls ProcessRepliesIfAny() in the first place, so if it is possible that, a new COPY message is appended after the already-queued CommandComplete? Which seems to violate the protocol, but I am not sure if that would lead to any trouble.

So, maybe we need a new helper, say ProcessPendingWritesForShutdown(), that loops while pq_is_send_pending(), call WalSndCheckShutdownTimeout() and only wait for WL_SOCKET_WRITEABLE, then pq_flush_if_writable(), on flush failure, maybe WalSndShutdown().

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/