[Triage] Error 500 on ASGI Worker with psycopg-pool

[sprezz-arthur]

Type

Bug Report

Description

After a couple requests, a django application running under ASGI Worker becomes unable to reuse the postgres connection pool.

Steps to Reproduce (for bugs)

Write down a minimal Django application using pyscopg-pool and run it under gunicorn's ASGI Worker.

I wrote down a MRE for this problem.

Configuration

gunicorn asgi:application --worker-class asgi --workers 1 --bind 0.0.0.0:8000

Logs / Error Output

No response

Gunicorn Version

gunicorn 26.0.0

Python Version

Python 3.14.5

Worker Class

asgi (beta)

Operating System

MacOS

Additional Context

No response

Checklist

• I have searched existing discussions and issues for duplicates
• I have checked the documentation and FAQ

[CarlosOliveira-23]

SUMMARY

The bug is a regression introduced in Gunicorn 25.2.0, not fully resolved
in 26.0.0. It is triggered specifically by the combination of Gunicorn's
built-in ASGI worker and Django's psycopg connection pool.

OBSERVATIONS (from MRE)

Gunicorn 25.1.0 + asgi worker + pool -> WORKS
Gunicorn 26.0.0 + asgi worker + pool -> FAILS (hangs after ~5 requests)
Gunicorn 26.0.0 + uvicorn worker + pool -> WORKS
Gunicorn 26.0.0 + asgi worker + pool OFF -> WORKS

ROOT CAUSE (likely)

Gunicorn's built-in ASGI worker does not fully respect the async lifecycle
that psycopg-pool requires. The pool uses asyncio internally to manage
connections, but the ASGI worker appears to run the event loop in a way
that causes the pool to deadlock — connections are checked out but never
properly returned, exhausting the pool after a few requests.

The underlying fix would need to happen in how Gunicorn's ASGI worker
manages the asyncio event loop and task lifecycle, ensuring the pool's
async context managers (aenter / aexit) are always properly
awaited even when a request ends abruptly.

WORKAROUNDS

OPTION 1 — Switch to the uvicorn worker (recommended)

Your own MRE confirms this works. The uvicorn worker is also the
recommended production setup for Django ASGI apps:

gunicorn asgi:application
--worker-class uvicorn.workers.UvicornWorker
--workers 1
--bind 0.0.0.0:8000

Install uvicorn if needed:
pip install uvicorn

OPTION 2 — Disable the psycopg pool temporarily

In your Django DATABASES settings, remove the pool option:

DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"OPTIONS": {}, # remove "pool": True
...
}
}

This falls back to per-request connections. Not ideal for performance,
but unblocks you immediately.

OPTION 3 — Pin to Gunicorn 25.1.0

The last known-good version before the regression:

pip install gunicorn==25.1.0

Not a long-term fix, but useful to confirm the regression and keep
things running while waiting for an official patch.

REFERENCES

• Related issue (partial fix): [Triage] 25.2.0 Update Results in Permanent 500 Internal Server Error on ASGI #3576
• MRE repo: https://github.com/ArthurSNCF/gunicorn-mre
• psycopg pool docs: https://www.psycopg.org/psycopg3/docs/advanced/pool.html
• Django ASGI + uvicorn guide: https://docs.djangoproject.com/en/stable/howto/deployment/asgi/uvicorn/