Re: libpq connection status and closed fd

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

In response to

Browse pgsql-hackers by date

  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