server_side_cursors cursor name clash (patch included)

[Former user]

The cursor name for server_side_cursors for psycopg2 is randomly generated as: ident = "c" + hex(random.randint(0, 65535))2:

I'm running a long select (millions of rows), but it's too slow when using limit/offset because it's a complicated query. server_side_cursors occasionally fails because it runs the long query in an outer loop and, in the inner loop, it performs selects where the cursor occasionally ends up with the same name as the one in the outer loop (at least that's what I suspect is happening because it ends up randomly failing with a "cursor already exists" error).

Solution: Increment the cursor name (e.g. c1, c2, c3). Unfortunately, I haven't written a unit test for the patch as it's rather complicated to test a random event on big tables, but the patch does fix the problem for me (tested on 0.4.4 but patched to SVN). It should work in the general case because cursors are local to a postgres connection, so c1 can exist in multiple connections.

[Former user]

patch

[Former user]

Oops, forgot to add a cc.

You can contact me at vomjom at vomjom.net

[Mike Bayer]

bf77ddaabb8a39f292a649e51f84e8a9af397de7 generally gets server side cursors working again and adds some better test coverage. For this particular issue I added the hex id of the ExecutionContext itself to the ID as well as the random number. the ExecutionContext lasts as long as the execution itself does so that will be unique within a single process - the random number helps with cross-process conflicts.