Re: Differentiating various OperationalError 'states'

On Wed, Feb 05, 2014 at 01:55:02PM +0100, Mario Splivalo wrote:

> On 02/04/2014 05:52 PM, Daniele Varrazzo wrote:
> > On Tue, Feb 4, 2014 at 3:31 PM, Mario Splivalo <mario@splivalo.hr> wrote:
> >
> >> Is there a better (more proper) way do figure out what went wrong when
> >> OperationalException is thrown?
> >
> > Apparently no, or not always: an error such as connection refused
> > (purely client side) doesn't generate any errcode (e.g. grep for
> > "could not connect to server" into postgres source
> > src/interfaces/libpq/fe-connect.c).
> >
> > An error returned by the backend may have a sqlcode set though:
> > grepping for "no pg_hba.conf entry for host" into
> > src/backend/libpq/auth.c shows an error code is set indeed: in this
> > case maybe psycopg is doing the wrong thing.
> >
> > So maybe we could present some more informations through the
> > exception's sqlstate, but looking at the available error codes I
> > wouldn't expect much more than a classification among "invalid auth",
> > "bad password", "any other unknown reason".
>
> Well, I actually need to know if 'remote service is down' (connection
> refused and/or connection timed out) vs 'remote service is up but you
> can not connect to it because of whatever...' (no pg_hba.conf entry and
> etc).
>
> What comes to mind now is 'postmaster is in recovery state', or
> 'postmaster is shutting down' too.

You might want to look at

    http://www.postgresql.org/docs/9.3/static/app-pg-isready.html

Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346