Как лучше решить ошибку — 'cursor «...» does not exist' при использование пуллера?

Ошибка cursor does not exist при использовании пуллера чаще всего связана с PostgreSQL server-side cursors и PgBouncer в режиме transaction pooling. Django может создать именованный курсор в одной транзакции/соединении, а следующий запрос попадает уже на другое серверное соединение. В итоге cursor, который был создан ранее, “исчезает”.

Если у вас Django + PostgreSQL + PgBouncer, первое, что нужно проверить — режим пула. В transaction pooling нельзя безопасно полагаться на server-side cursors. Решения два: отключить server-side cursors в Django или перевести PgBouncer в session pooling для этого приложения.

Для Django обычно помогает настройка:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": "app",
        "USER": "app",
        "PASSWORD": "secret",
        "HOST": "pgbouncer",
        "PORT": "6432",
        "DISABLE_SERVER_SIDE_CURSORS": True,
    }
}

Также проверьте места, где используется QuerySet.iterator(), большие выгрузки, streaming responses и ручная работа с cursor. Такие сценарии часто включают server-side cursor, чтобы не держать весь результат в памяти. С PgBouncer в transaction mode это ломается.

Если большие выборки действительно нужны, варианты такие:

• подключаться к PostgreSQL напрямую для job/экспорта;
• использовать PgBouncer session pooling;
• разбивать выгрузку на страницы по id;
• отключить server-side cursors и контролировать память;
• не держать курсор между транзакциями.

Итог: это не “случайная ошибка Django”, а конфликт жизненного цикла курсора и пула соединений. Начните с DISABLE_SERVER_SIDE_CURSORS=True. Если после этого ошибка исчезла, причина подтверждена. Дальше уже решайте архитектурно: session pooling для таких операций или отказ от курсоров в пользу батчевой обработки.