Skip Menu |

This queue is for tickets about the DBD-Pg CPAN distribution.

Report information
The Basics
Id: 44744
Status: resolved
Priority: 0/
Queue: DBD-Pg

People
Owner: greg [...] turnstep.com
Requestors: rweikusat [...] mssgmbh.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 2.13.0



Subject: connection failure reported as 'data exception' (22000)
After a libpq-function has been executed in dbdimp.c, the _sqlstate-routine is used to fill the sqlstate-buffer of an implementation database handle structure with a sensible SQLSTATE value, based on the PGresult returned by the original call and the PG_DIAG_SQLSTATE value which can be queried from it. In absence of this information, the code tries to map the PQresultStatus-value associated with the PGresult to a SQLSTATE on its own. In particular, a status-value of PGRES_FATAL_ERROR will be translated to a 'data exception'-code (22000). This is the default action if no other information was available, including the case where the PGresult * passed to _sqlstate was NULL. But returning a NULL PGresult * is the way libpq-routines signal a connection failure to their callers. Using SQLSTATE 08006 ('connection failure') seems more appropriate for this case. The attached file contains a patch changing the code to do so.
Subject: 08006.txt
Index: DBD-Pg/dbdimp.c =================================================================== RCS file: /sysdata/cvs/DBD-Pg/dbdimp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.4.1 diff -u -r1.1.1.1 -r1.1.1.1.4.1 --- DBD-Pg/dbdimp.c 1 Apr 2009 15:18:00 -0000 1.1.1.1 +++ DBD-Pg/dbdimp.c 2 Apr 2009 11:28:59 -0000 1.1.1.1.4.1 @@ -377,6 +377,12 @@ strncpy(imp_dbh->sqlstate, "01000", 6); /* WARNING */ break; case PGRES_FATAL_ERROR: + if (!result) { + /* CONNECTION FAILURE */ + strncpy(imp_dbh->sqlstate, "08006", 6); + break; + } + default: strncpy(imp_dbh->sqlstate, "22000", 6); /* DATA EXCEPTION */ break;
We already issue
On Tue Apr 07 14:49:02 2009, greg@turnstep.com wrote: Show quoted text
> We already issue
..ahem...as I was saying, we already issue a 08006 for a failure when logging in, maybe we can be more generic in this case and say 08000 or 08003?
Subject: Re: [rt.cpan.org #44744] connection failure reported as 'data exception' (22000)
Date: Thu, 09 Apr 2009 14:01:49 +0200
To: bug-DBD-Pg [...] rt.cpan.org
From: Rainer Weikusat <rweikusat [...] mssgmbh.com>
"Greg Sabino Mullane via RT" <bug-DBD-Pg@rt.cpan.org> writes: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=44744 > > > On Tue Apr 07 14:49:02 2009, greg@turnstep.com wrote:
>> We already issue
> > ..ahem...as I was saying, we already issue a 08006 for a failure when > logging in, maybe we can be more generic in this case and say 08000 or > 08003?
'connection failure' just sounded like a sensible choice to me. The problem behind this is that 'some code' (like the one I am presently working one) may need to be able to distinguish between 'existing connection was severed for some reason' (eg someone restarted the DB-server) and 'unexpected failure occurred'. In the first case, a client could (and IMO should) try to reconnect (a couple of times) before giving up, while the second would usually warrant further inspection, in order to determine a 'handling strategy' for the actual problem.
Okay, applied in r12682 as SQLSTATE 08000, a generic "CONNECTION EXCEPTION" as opposed to the default of "DATA EXCEPTION". Thanks for the patch. If you still feel strongly about the exact code used, I'm open to persuasion. :)