The DB is at max_connections=100 and several stack services hold persistent
pools (several as the postgres superuser, idle for hours), so peaks hit
"too many connections". The MCP is a minor contributor but easy to bound:
- Dockerfile: uvicorn --workers 2 → 1. The MCP's connection budget is
workers × MCP_POOL_MAX, so this caps it at 8 backends instead of 16. Scale
via MCP_POOL_MAX, not workers, so the budget stays obvious. (Pairs with the
minconn=0 lazy pool already on this branch: 0 connections held when idle.)
- analytics_ro_role.sql: add idle_session_timeout=5min so the DB reaps the
MCP's idle POOLED connections (idle_in_transaction never reaps them — they're
idle outside a txn) and returns the slots. Safe because the server now
discards + transparently retries a reaped connection instead of erroring.
Note: the dominant fix is stack-wide (get the superuser app pools onto bounded,
timed roles; consider PgBouncer; or raise max_connections) — out of this repo's
scope but documented in the review.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The analytics_ro role only had USAGE/SELECT on reporting + tracksolid, so
the tickets schema (INC/CRQ, 8 tables + 1 view + 7 fns) and fuel schema
were invisible to the MCP server — queries failed with permission denied.
- analytics_ro_role.sql: GRANT USAGE/SELECT/EXECUTE on tickets + fuel.
Default privileges for these are keyed to postgres (their owner), not
tracksolid_owner, so future objects auto-grant correctly.
- analytics_mcp.py: READABLE_SCHEMAS now includes tickets + fuel and is
overridable via MCP_READABLE_SCHEMAS, so the introspection helpers
(list_tables/describe_table/sample_table) work for them too.
- deploy.sh: reuse existing analyst tokens from the running container when
MCP_AUTH_TOKENS is unset, so a code-only redeploy needs no secret.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
