Re: Windows: Wrong error message at connection termination - Mailing list pgsql-hackers

From Sergey Shinderuk
Subject Re: Windows: Wrong error message at connection termination
Date
Msg-id c093f68b-be35-df40-b2fd-e0b167bddf4f@postgrespro.ru
Whole thread Raw
In response to Re: Windows: Wrong error message at connection termination  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Windows: Wrong error message at connection termination
Re: Windows: Wrong error message at connection termination
List 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/



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Multi-Column List Partitioning
Next
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] New default role allowing to change per-role/database settings