Re: libpq connection status and closed fd - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: libpq connection status and closed fd
Date
Msg-id 541FE840.5070908@joh.to
Whole thread Raw
In response to Re: libpq connection status and closed fd  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 9/22/14 10:57 AM, Andres Freund wrote:
> On 2014-09-22 07:42:01 +0100, Daniele Varrazzo wrote:
>> Is this intentional? Is there a better way to check for a broken connection?
>
> Note that the libpq code treats connection resets differently from
> other, arbitrary, errors:
>
> I.e. if the kernel returns that the connection has been closed it'll do
> different stuff.
>
> So I'm not convinced that the testcaseq is valid. This isn't the error
> you'd get after a timeout or similar. We could add a special case path
> for EBADFD, but why?

Probably not for EBADFD, but how about e.g. ETIMEDOUT?  The SSL code 
path seems to be putting EPIPE into the same category as ECONNRESET, too.


.marko



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: libpq connection status and closed fd
Next
From: Rahila Syed
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes