| 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: | Whole Thread | Raw Message | 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 |