mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-12 20:29:10 +02:00
07034f4455
* feat(server): configurable pgxpool size with sane defaults pgxpool.New(ctx, url) silently sets MaxConns = max(4, NumCPU). On the prod pods that resolved to 4, which got fully saturated by daemon claim/heartbeat traffic (~3800 acquires/s) and showed up as ~900ms acquire waits on every query — the actual root cause of the 3s+ /tasks/claim tail latency. The db pool stats logging from #1378 confirmed this with empty_acquire_delta == acquire_count_delta. Switch to pgxpool.ParseConfig + NewWithConfig and apply per-pod defaults of MaxConns=25 / MinConns=5, both overridable via env vars (DATABASE_MAX_CONNS / DATABASE_MIN_CONNS) so the size can be tuned in prod without a redeploy. The defaults follow the standard 'small pool, lots of waiters' guidance for Postgres (PG community / HikariCP formula `(core_count * 2) + effective_spindle_count`); 25 leaves headroom for bursts and occasional long queries while staying safely under typical managed-Postgres max_connections ceilings when multiplied across pods. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(server): respect DATABASE_URL pool_* params; add precedence tests Address review feedback on #1381: - Configuration precedence is now explicit: DATABASE_MAX_CONNS env > pool_max_conns query param on DATABASE_URL > built-in default. Same for min_conns. Previously the env-empty path unconditionally overwrote whatever ParseConfig had read from the URL — a silent regression for deployments that already tuned pool size via the connection string. - Add unit tests in dbstats_test.go covering each precedence branch (defaults, URL-only, env-over-URL, partial URL, invalid env, min>max clamp). - Move pool tuning vars out of 'Required Variables' into a new 'Database Pool Tuning (Optional)' section in SELF_HOSTING_ADVANCED.md so self-hosters don't think they need to set them. - Add commented entries in .env.example. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(server): invalid pool env falls back to URL/code default, never pgx 4 Address second round of review on #1381: Previous code passed cfg.MaxConns / cfg.MinConns as the envInt32 fallback, which meant an invalid DATABASE_MAX_CONNS value silently fell back to ParseConfig's value — i.e. pgx's built-in default of 4/0 when the URL had no pool_* params. That's exactly the bad value this PR exists to remove, and the previous test (TestPoolSizing_InvalidEnvFallsBack) accidentally locked it in. Compute the non-env fallback first (URL pool_* if present, else code default 25/5) and pass that to envInt32. Misconfigured env now lands on the same value as if the env were unset — never on the pgx default. Replace the loose 'max > 0' assertion with two precise tests: - invalid env + no URL param → code default (25/5) - invalid env + URL param → URL value Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>