#29760: Cursors are being closed explicitly in autocommit mode
-------------------------------------+-------------------------------------
     Reporter:  Ali Teoman Unay      |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  1.11
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  cursor, sql,         |             Triage Stage:
  database, autocommit,              |  Unreviewed
  transactions, postrgresql,         |
  psycopg                            |
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Ali Teoman Unay):

 Replying to [comment:5 Tim Graham]:
 > Can you give steps to reproduce the error?
 >
 > I read the psycopg2 docs that you linked to but I didn't spot the place
 where it says "server-side cursors should not be closed explicitly if it
 is in autocommit mode."

 "Named cursors are usually created WITHOUT HOLD, meaning they live only as
 long as the current transaction. Trying to fetch from a named cursor after
 a commit() or to create a named cursor when the connection is in
 autocommit mode will result in an exception. It is possible to create a
 WITH HOLD cursor by specifying a True value for the withhold parameter to
 cursor() or by setting the withhold attribute to True before calling
 execute() on the cursor. It is extremely important to always close() such
 cursors, otherwise they will continue to hold server-side resources until
 the connection will be eventually closed. Also note that while WITH HOLD
 cursors lifetime extends well after commit(), calling rollback() will
 automatically close the cursor."

 from [http://initd.org/psycopg/docs/usage.html#server-side-cursors here]

 It is hard to reproduce the error since it appears each time in a
 different line of our code and it is very rare. I believe it appears when
 the cursor is destroyed before the transaction ended and it points to a
 synchronization error which might be related to this issue.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/29760#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.7421ecda47fb46d9162b93b84c9b2887%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to