Thread: Connection failures when using green
Hi,
I'm starting to use psycopg2 together with greenlet/gevent and I noticed that when green psycopg2 connection errors are useless, since they always raise "asynchronous connection failed" exception and there's no way to know what exactly went wrong. Turns out that the patch for this is trivial (which I'm using), but I'm wondering if there's some underlying reason it wasn't done like that in the first place?
diff --git a/psycopg/connection_int.c b/psycopg/connection_int.c
index 7851b0a..feb4196 100644
--- a/psycopg/connection_int.c
+++ b/psycopg/connection_int.c
@@ -656,7 +656,7 @@ _conn_poll_connecting(connectionObject *self)
break;
case PGRES_POLLING_FAILED:
case PGRES_POLLING_ACTIVE:
- PyErr_SetString(OperationalError, "asynchronous connection failed");
+ PyErr_SetString(OperationalError, PQerrorMessage(self->pgconn));
res = PSYCO_POLL_ERROR;
break;
}
Best regards,
Alexey.
Attachment
On Sun, Jul 21, 2013 at 3:33 PM, Alexey Borzenkov <snaury@gmail.com> wrote: > Hi, > > I'm starting to use psycopg2 together with greenlet/gevent and I noticed > that when green psycopg2 connection errors are useless, since they always > raise "asynchronous connection failed" exception and there's no way to know > what exactly went wrong. Turns out that the patch for this is trivial (which > I'm using), but I'm wondering if there's some underlying reason it wasn't > done like that in the first place? Thank you for the patch. Not sure why it wasn't done in first place: I assume during testing we found failure modes that didn't populate the connection error message. I think it would be ok to return the error message from the connection as your patch proposes, falling back on the generic error message in case the former is empty. -- Daniele