Re: Problem with error handling - Mailing list psycopg

Daniele,

Thanks for jumping on this.  Interestingly, you did exactly the same
thing that I did in the else (set DatabaseError).  And yes, it did fix
my problem, so you are spot on.

As to the error, here is the relevant piece of our code:

            cur = self.conn.cursor(wrapped=0)
            logger.debug(cur.mogrify(sql, values))
            logger.debug("before: %s" % cur)
            cur.execute(sql, values)
            logger.debug("after: %s" % cur)
            return cur

The call to cur.execute was raising an exception because the connection
had closed.  It was still open during the logger entry for "before".  It
closed sometime during the execute call.  It made it to the call to "
_psyco_curs_execute ", so none of the other failure conditions prior to
that in "psyco_curs_execute" were triggered.  Maybe they should have
been or maybe not.  Maybe they caused the connection to close or maybe
not.  Probably not.  Regardless, it runs into trouble when it gets to
the locking portion of the query execution.

Here's the relevant output from the debugging log:

[20299] curs_execute: pg connection at 0x859a000 OK
[20299] pq_begin_locked: pgconn = 0x859a000, isolevel = 1, status = 1
[20299] pq_execute_command_locked: pgconn = 0x859a000, query = BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
[20299] pq_execute_command_locked: result was not COMMAND_OK (7)
[20299] pq_complete_error: pgconn = 0x859a000, pgres = 0x8125a80, error
= (null)
[20299] pq_raise: PQerrorMessage: err=server closed the connection
unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

[20299] pq_raise: err2=server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

[20299] psyco_curs_execute: res = -1, pgres = 0x0

I am guessing that this is an issue with our database more than with
psycopg.  It works if we catch the exception and re-connect.  We are
using postgresql 8.1 on FreeBSD 4.8 (without pthreads).  The postgres
connection is made over stunnel.  Keep in mind that we are currently in
the process of moving to postgres 9 and RHEL 5 in the coming weeks.
Regardless, thanks for your timely attention on this matter.

-eric

-----Original Message-----
From: Daniele Varrazzo [mailto:daniele.varrazzo@gmail.com]
Sent: Saturday, April 23, 2011 8:07 PM
To: Eric Snow
Cc: psycopg@postgresql.org
Subject: Re: [psycopg] Problem with error handling

On Sun, Apr 24, 2011 at 2:47 AM, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
> On Sat, Apr 23, 2011 at 2:56 AM, Eric Snow <esnow@verio.net> wrote:

>> * "exc" should have been calculated another way (like an else after
>> the "if (code != NULL)")
>
> Definitely there should have been an else here: We check for the state

> not null but then don't do anything as an alternative. I don't think
> passing a NULL to psyco_set_error was ever intentional. Fixing in my
> repos.

I have fixed the issue
<https://github.com/dvarrazzo/psycopg/commit/c08799b0>, but the error
may be unhelpful if the libpq didn't provide a message either.

Do you have a way to reproduce the bug so we can see if there is any
other hint we can provide as exception message? If not, would you mind
testing the patch and see if you get a reasonable error?

Thanks,

-- Daniele


This email message is intended for the use of the person to whom it has been sent, and may contain information that is
confidentialor legally protected. If you are not the intended recipient or have received this message in error, you are
notauthorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender
immediatelyby return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that
thisemail is error or virus free.  Thank you.