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/ |