Re: Exit walsender before confirming remote flush in logical replication

On Wed, Apr 8, 2026 at 4:05 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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