id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 28062 Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor errors Sergey Fursov François Freitag "Hi! In our application stack we connect from our web/background workers to postgres database through dedicated pgBouncer service. pgBouncer is running in transaction pooling mode and django connections work in autocommit mode. After upgrading to 1.11 version with new server-side cursors for queryset iterators, many of our DB requests were started failing with ""Cursor _django_curs_ does not exist'. According to pgBouncer docs (https://wiki.postgresql.org/wiki/PgBouncer), it doesn't support using WITH HOLD cursors with transaction pooling mode. But it doesn't seems reasonable to run pgBouncer in session pooling mode. We can just switch to direct persistent connections to postgres DB, but in this case we have to increase minimum number of DB connection to number of our workers (from 5 to ~30-40) to prevent blocking requests and this will violate recommendation to have (core_count * 2) + effective_spindle_count max connections to DB (https://wiki.postgresql.org/wiki/Number_Of_Database_Connections). Introducing server-side cursors seems like breaking change in our case (and i guess many django apps use pgBouncer behind Postgres DB) So is there some recommendations how efficiently work with postgres DB in django 1.11? Looks like another possible option is wrapping all iterator() calls in their own transactions, but django internally use cursors in several places (e.g. in ModelChoiceIterator). I think this possible problem should be documented in some way, and it would be great to describe some options for projects to migrate to new version. Thanks, Sergey" Bug closed Database layer (models, ORM) 1.11 Release blocker fixed josh.smeaton@… mail@… lcannon@… Ready for checkin 1 0 0 0 0 0