Re: EOF error

On 28/02/2008, johnf <jfabiani-rLSQ/[email protected]> wrote:
> On Wednesday 27 February 2008 06:09:31 pm Chris Cogdon wrote:
>  > On Feb 27, 2008, at 17:47 , johnf wrote:
>
> > > On Wednesday 27 February 2008 05:23:59 pm you wrote:
>  > >> On Feb 27, 2008, at 15:37 , johnf wrote:
>  > >>> I got similar results.  I also get an entry into the log
>  > >>> "Abort"  when I use connection.close().  But I don't get anything
>  > >>> when I use
>  > >>> del connection.
>  > >>
>  > >> You have a transaction in progress at the time ? Ie, perhaps you did
>  > >> some select statements inside read_serializable mode ?
>  > >
>
> > > I doubt that.  I just open the connection and then make a select
>  > > and close.
>  >
>  > That would be a transaction ;) It happens under the hood in most
>  > (all?) python-postgresql connectors. Upon the first statement
>  > executed, the connector will open up a transaction, even if it's a
>  > simple select statement.
>  >
>  > So, I just repeated your experiment, with FULL debugging on, and I
>  > get this:
>  >
>  > 2008-02-27 18:10:46 PST (25214)> LOG:  statement: ABORT
>  >
>  > and if I do a "rollback" or a "commit" before I try and close, then I
>  > DONT get the ABORT.
>  >
>  > So, yeah, you're inside a transaction,even after a simple select.
>
>  OK so what is a guy suppose to do?  It seems like a no win situation.

If you can produce a minimal test case, please file a bug report at
http://www.initd.org/tracker/psycopg/ and attach it there.

This sounds a lot like a reference loop, so having a minimal example
would be helpful in debugging it.

The fix will most likely involve adding tp_traverse() methods to some
of the types in psycopg (which will allow the cycle GC to find the
loops).

It might also be necessary to add tp_clear() methods to some (to let
the GC break the loops).

James.