On Wed, Apr 8, 2026 at 4:05 PM Chao Li <[email protected]> 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
