Re: Windows: Wrong error message at connection termination
Sergey Shinderuk <s.shinderuk@postgrespro.ru>
From: Sergey Shinderuk <s.shinderuk@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>, Alexander Lakhin <exclusion@gmail.com>
Cc: Lars Kanis <lars@greiz-reinsdorf.de>,
Thomas Munro <thomas.munro@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-01-14T10:01:39Z
Lists: pgsql-hackers
On 02.12.2021 22:31, Tom Lane wrote: > I'll push the close-only change in a little bit. Unexpectedly, this changes the error message: postgres=# set idle_session_timeout = '1s'; SET postgres=# select 1; could not receive data from server: Software caused connection abort (0x00002745/10053) The connection to the server was lost. Succeeded. postgres=# Without shutdown/closesocket it would most likely be: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. 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). Without shutdown/closesocket, after the timeout expires, the server sends the error message, the client sends an ACK, and the server responds with a RST. Then psql tries to sends the next query, but nothing is sent at the TCP level, and the next recv() returns WSAECONNRESET. IIUIC, in both cases we may or may not recv() the error message from the server depending on how fast the RST arrives from the server. Should we handle ECONNABORTED similarly to ECONNRESET in pqsecure_raw_read? -- Sergey Shinderuk https://postgrespro.com/
Commits
-
On Windows, close the client socket explicitly during backend shutdown.
- 00cd81723cd0 10.20 landed
- a87c8c3edd7f 11.15 landed
- 3e644dcca1e9 12.10 landed
- 6251f86241ac 13.6 landed
- 4cd2928543c1 14.2 landed
- 6051857fc953 15.0 landed