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