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

  1. On Windows, close the client socket explicitly during backend shutdown.