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

From Dmitriy Igrishin
Subject Re: libpq connection status and closed fd
Date
Msg-id CAAfz9KPXzfXGRoRwY47fuJzxGWvpMwn_ZQi36jsruyC8WzSS6g@mail.gmail.com
Whole thread Raw
In response to libpq connection status and closed fd  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Responses Re: libpq connection status and closed fd
List pgsql-hackers


2014-09-22 10:42 GMT+04:00 Daniele Varrazzo <daniele.varrazzo@gmail.com>:
Hello,

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 (I don't know if the two conditions result in the same
effect, but I'll stick to this hypothesis for now).

[1] https://github.com/psycopg/psycopg2/issues/263

Testing with a short C program [2] it seems that indeed, after closing
the fd and causing an error in `PQconsumeInput`, the connection is
deemed in good state by `PQstatus`. A similar test gives the same
result after `PQexec` is attempted on a connection whose fd is closed
(tests performed with PostgreSQL 9.3.5).

[2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f
Why are you using close() instead of PQfinish()?


Is this intentional? Is there a better way to check for a broken connection?
BTW, PQsocket() returns -1 after PQfinish(). 

If we mark the connection as closed every time `PQconsumeInput`
returns 0 (or `PQexec` returns null, which are the two code paths
affecting psycopg) would it be too aggressive and cause false
positives?

Thank you very much.

-- Daniele


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



--
// Dmitriy.

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Index scan optimization
Next
From: Daniele Varrazzo
Date:
Subject: Re: libpq connection status and closed fd