From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | 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 13:54:15 |
Message-ID: | 12708.1411394055@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
> a psycopg user is reporting [1] that the library is not marking the
> connection as closed and/or bad after certain errors, such as a
> connection timeout. He is emulating the error by closing the
> connection fd
That seems like a completely illegitimate test procedure. A network
failure does not result in automatic closure of the FD so there is
no reason for the libpq code to be expecting that to happen. Instead,
it expects to see an appropriate error code next time it tries to
use the socket.
If you want to test for connection loss, consider doing a kill -9 on
the connected backend (best not to do that with a production server
of course).
A larger point is that your user may well have false expectations
about how quickly libpq will detect connection loss. Generally
that won't happen until it next tries to transmit or receive some
data; so a simple PQstatus() call doesn't prove a lot about whether
the connection has been lost since the last query. This is not a
bug either IMO.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2014-09-22 13:55:59 | Re: Yet another abort-early plan disaster on 9.3 |
Previous Message | Heikki Linnakangas | 2014-09-22 13:46:55 | Re: Index scan optimization |