Re: Exit walsender before confirming remote flush in logical replication

On Wed, Apr 8, 2026 at 4:05 PM Chao Li <li.evan.chao@gmail.com> wrote:
> I have some CF entries failed on this test case as well, so I tried to look into the problem.

Thanks for working on this, much appreciated!


> Once entering WalSndDone(), it might call pg_flush() and get stuck:
> ```
>         if (WalSndCaughtUp && sentPtr == replicatedPtr &&
>                 !pq_is_send_pending())
>         {
>                 QueryCompletion qc;
>
>                 /* Inform the standby that XLOG streaming is done */
>                 SetQueryCompletion(&qc, CMDTAG_COPY, 0);
>                 EndCommand(&qc, DestRemote, false);
>                 pq_flush();
>
>                 proc_exit(0);
> ```
>
> And once stuck, it will never get back to WalSndCheckShutdownTimeout(), so the new GUC timeout cannot rescue it.

pq_flush() is called when WalSndCaughtUp && sentPtr == replicatedPtr
&& !pq_is_send_pending().
Under these conditions, I was thinking that we can assume the kernel send
buffer isn't full, so pq_flush() (i.e., the send() call) can copy the data
without blocking and return immediately.

I'm not very familiar with FreeBSD, but based on [1], I wonder if this
assumption may not hold there, and pq_flush() could still block....

Regards,

[1] https://man.freebsd.org/cgi/man.cgi?unix(4)#BUFFERING

> Due  to the local nature of the Unix-domain sockets, they do not imple-
> ment send buffers.  The send(2) and write(2) families of system calls
> attempt to write data to the receive buffer of the destination socket.

-- 
Fujii Masao