From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq connection status and closed fd |
Date: | 2014-09-22 09:13:36 |
Message-ID: | 541FE840.5070908@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Rahila Syed | 2014-09-22 09:45:44 | Re: [REVIEW] Re: Compression of full-page-writes |
Previous Message | Andres Freund | 2014-09-22 08:57:10 | Re: libpq connection status and closed fd |