On Wed, Apr 22, 2026 at 3:32 AM Fujii Masao <[email protected]> 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
Description: Binary data
