| 
     
      
      
      From: Mike C. F. <mcf...@ro...> - 2004-02-25 07:27:18
      
     
   | 
I've just recently upgraded to postgresql 7.4 on cygwin, and am now 
seeing some strange behaviour of PyPgSQL cursors.  There were a number 
of changes to the semantics of cursor lifetimes in the 7.3 to 7.4 
transition, so I'm wondering if they might be the source of the 
problems, and if so, if anyone has worked around them already.
Basically the symptoms are that in a large application, I'm getting 
operational errors raised like that below (I've been unable to duplicate 
the effect in small test-scripts, unfortunately).  The errors are 
consistently seen with certain tests.  The code in question is using a 
single connection, creating temporary cursors for individual 
(sequentially occurring) operations.  There's no threading going on.  
This is with the latest PyPgSQL:
(self.conn.conn is: <Opened PgConnection at 013D19E0>)
Traceback (most recent call last):
  File "p:\sharedinstall\pyPgSQL\PgSQL.py", line 3098, in execute
    self.res = self.conn.conn.query(_qstr % parms)
OperationalError: ERROR:  cursor "PgSQL_013CAD78" already exists
I've been playing with adding a serial number to the name of the cursor, 
and it does appear as though the same cursor object is attempting to 
multiply-create itself during the query call (as opposed to a chance 
duplication of memory address causing two temporally disjoint cursors to 
share the same name).
I'm thinking I'll have to regress to PostgreSQL 7.3 for now, but would 
love to hear if anyone has encountered and/or worked around the issue.
Thoughts appreciated,
Mike
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
 |