You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prod sits at 6 connections because real logins are spread across many different users — different rows, so no lock contention. The dev reproduction hammered a single user, which is what made it visible.
The fault is latent, not absent. A burst of logins on one account, or simply higher concurrency, hits the same wall: requests queue on the ds_user row lock, each holding a database connection, until max_connections is exhausted. On dev that produced 500s (too many clients already), 504s, and a deploy pipeline that could not run manage.py.
And because prod's health check has the same blindness, /health/ would keep returning 200 healthy throughout — exactly as it did on dev — so nothing would page.
Complication: prod is not on this pipeline
prod-cds runs a locally built image (dataexbackend-backend), not the GHCR image the dev CD pipeline builds and digest-pins. So these fixes do not reach prod by merging to dev; shipping them is a separate manual path.
The three defects fixed on dev (#134, #139, #140) are still present on prod-cds. Verified read-only on the running container:
prod-cdsuser.save()(row-lock fix, #136)site-packages/nvidiamax_connections/ current connectionsWhy it has not shown up yet
Prod sits at 6 connections because real logins are spread across many different users — different rows, so no lock contention. The dev reproduction hammered a single user, which is what made it visible.
The fault is latent, not absent. A burst of logins on one account, or simply higher concurrency, hits the same wall: requests queue on the
ds_userrow lock, each holding a database connection, untilmax_connectionsis exhausted. On dev that produced 500s (too many clients already), 504s, and a deploy pipeline that could not runmanage.py.And because prod's health check has the same blindness,
/health/would keep returning200 healthythroughout — exactly as it did on dev — so nothing would page.Complication: prod is not on this pipeline
prod-cdsruns a locally built image (dataexbackend-backend), not the GHCR image the dev CD pipeline builds and digest-pins. So these fixes do not reach prod by merging todev; shipping them is a separate manual path.Suggested
SELECT count(*), state FROM pg_stat_activity GROUP BY state;to confirm prod's steady-state headroom.Not actioned: changes on prod are owner-authorised only.