Thread: Differentiating various OperationalError 'states'
Hello.
I'd like to differentiate between:
- FATAL: no pg_hba.conf entry for host blah-blah
- could not connect to server: Connection Refused
- timeout expired
It seems that the only way to do so is to parse the string
OperationalError returns, something like this:
try:
conn = psycopg2.connect(conn_string)
except psycopg2.OperationalError as err:
if str(err).startswith('FATAL: no pg_hba'):
# do stuff
...
Is there a better (more proper) way do figure out what went wrong when
OperationalException is thrown?
Mario
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". -- Daniele
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.
I'm just afraid that the strings will change in the future.
But, thank you for the input, string parsing it is, then.
Mar
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