From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Windows socket problems, interesting connection to AIO |
Date: | 2024-09-10 22:40:52 |
Message-ID: | 20240910224052.7a.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 02, 2024 at 09:20:21PM +1200, Thomas Munro wrote:
> 2. If a Windows client tries to send() and gets an ECONNRESET/EPIPE
> error, then the network stack seems to drop already received data, so
> a following recv() will never see it. In other words, it depends on
> whether the application-level protocol is strictly request/response
> based, or has sequence points at which both ends might send(). AFAIK
> the main consequence for real users is that FATAL recovery conflict,
> idle termination, etc messages are not delivered to clients, leaving
> just "server closed the connection unexpectedly".
> The new thought I had about the second category of problem is: if you
> use asynchronous networking APIs, then the kernel *can't* throw your
> data out, because it doesn't even have it. If the server's FATAL
> message arrives before the client calls send(), then the data is
> already written to user space memory and the I/O is marked as
> complete.
Good point.
> just wanted to share this observation.
Thanks for sharing that and the test program.
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2024-09-11 01:02:50 | Re: Make printtup a bit faster |
Previous Message | Noah Misch | 2024-09-10 22:38:38 | Re: Use read streams in pg_visibility |