Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Nov 22, 2021 at 10:42 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It'd be useful to check if Lars' patch cures that symptom.
> Yeah, it sounds like it might solve at least the server-side problem.
> Let's call that weird behaviour #1: RST on process exit. (I wonder if
> my keep-the-socket-open-in-another-process thought experiment is
> theoretically better: a lingering socket should be capable of
> resending data that hasn't been ack'd yet in FIN-WAIT-1 state after
> close, which I suspect might not happen if the TCP stack nukes the
> socket. If close() avoids the proactive RST but still doesn't really
> follow the shutdown protocol then it's papering over a crack in the
> wall, but I'm not planning to argue about that...)
The language about "graceful shutdown" in the Windows docs at least
suggests that they finish out the TCP connection cleanly; failing
to retransmit at need would hardly qualify as "graceful". Of course,
Redmond keeps finding ways to fail to meet reasonable expectations.
> IIUC we'd still have weird behaviour #2 on the client side: TCP stack
> drops buffered received data on the floor on receipt of RST.
Do we know that that actually happens in an arm's-length connection
(ie two separate machines)? I wonder if the data loss is strictly
an artifact of a localhost connection. There'd be a lot more pressure
on them to make cross-machine TCP work per spec, one would think.
But in any case, if we can avoid sending RST in this situation,
it seems mostly moot for our usage.
regards, tom lane