Detecting backend failures via libpq / DBD::Pg - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Detecting backend failures via libpq / DBD::Pg
Date
Msg-id 222ee9a6852de9bafd157b57783bcf3d@biglumber.com
Whole thread Raw
Responses Re: Detecting backend failures via libpq / DBD::Pg
Re: Detecting backend failures via libpq / DBD::Pg
Re: Detecting backend failures via libpq / DBD::Pg
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

I am working on enhancing the ping() method of DBD::Pg. The goal of that 
is for a user to be able to determine if the connection to the database 
is still valid. The basic way we do this is to send a simple SELECT via 
PQexec and then check for a valid return value (and when in doubt, we check 
PQstatus). This works fine for most transaction statuses, including idle, 
active, and idle in transaction. It even works for copy in and copy out, 
although it obviously invalidates the current COPY (caveat emptor!). 
The problem comes when ping() is called and we are in a failed transaction. 
After some experimenting, the best solution I found is to send the PQexec, 
and then check if PQresultErrorField(result, 'C') is '25P02'. If it is, then 
all is "well", in that the server is still alive. If it is not, then we 
can assume the backend is bad (for example, PQerrorMessage gives a 
"could not receive data from server: Bad file descriptor"). Being that we 
cannot do a rollback before calling the PQexec, is this a decent solution? 
Can we depend on really serious errors always trumping the expected 25P02?

- -- 
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201412291942
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlSh9QEACgkQvJuQZxSWSsjDMQCg3CO1eyrFXNUnfRbk/rRJmrCl
PEoAnRl+M67kTkuZDi+3zMyVyblLvl9I
=uW6Q
-----END PGP SIGNATURE-----





pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: BUG #12330: ACID is broken for unique constraints
Next
From: Jim Nasby
Date:
Subject: Re: Additional role attributes && superuser review