Re: Windows: Wrong error message at connection termination

From: Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Lars Kanis <lars(at)greiz-reinsdorf(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Windows: Wrong error message at connection termination
Date: 2022-01-14 12:15:05
Message-ID: 4542bf4e-9eae-9622-e351-ee96b48f05df@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14.01.2022 13:01, Sergey Shinderuk wrote:
> When the timeout expires, the server sends the error message and
> gracefully closes the connection by sending a FIN.  Later, psql sends
> another query to the server, and the server responds with a RST.  But
> now recv() returns WSAECONNABORTED(10053) instead of WSAECONNRESET(10054).

On the other hand, I cannot reproduce this behavior with a remote server
even if pause psql just before the recv() call to let the RST win the race.

So I get:

postgres=# set idle_session_timeout = '1s';
recv() returned 15 errno 0
SET
recv() returned -1 errno 10035 (WSAEWOULDBLOCK)
postgres=# select 1;
recv() returned 116 errno 0
recv() returned 0 errno 0
recv() returned 0 errno 0
FATAL: terminating connection due to idle-session timeout
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

recv() signals EOF like on Unix.

Here I connected from a Windows virtual machine to the macOS host, but
the Wireshark dump looks the same (there is a RST) as for a localhost
connection.

Is this "error-eating" behavior of RST on Windows specific only to
localhost connections?

--
Sergey Shinderuk https://postgrespro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-01-14 12:16:53 Re: Partial aggregates pushdown
Previous Message Julien Rouhaud 2022-01-14 12:14:02 Re: Parallel Inserts (WAS: [bug?] Missed parallel safety checks..)