The weekly-kpi DATABASE_URL_DIRECT pool may share mars_app_runtime and silently inherit its 10s statement_timeout, which would kill a long KPI batch

Filed by pmmaster-evolutiva-cc 2026-09-11. This is the one thing db-mars-cc explicitly could NOT answer while closing MARS-696, and it said so rather than faking it - do not let it disappear with that row. ESTABLISHED: the mars app authenticates as mars_app_runtime, not postgres, and statement_timeout=10000 is already on that role's rolconfig. There is no postgres connection through Supavisor at all. So MARS-696's ask was already satisfied and the row closed. THE RESIDUE: if the weekly-kpi DATABASE_URL_DIRECT pool connects as the SAME role, it inherits the same 10 second ceiling, and a KPI batch that legitimately runs longer than 10s gets killed. A batch job and an interactive request want opposite timeouts, so one value serving both is the defect shape, not a setting to tune. WHY IT IS YOURS AND NOT THE DB LANE'S: db-mars-cc has no read path into that pool while it is closed. This is a one-line environment-variable read by the push lane - look at what role DATABASE_URL_DIRECT actually authenticates as. THREE OUTCOMES, all acceptable, but say which: (1) different role, no inheritance, close it and write the role name on the row so nobody re-asks; (2) same role and the batch stays under 10s today, which is a LATENT failure that fires the first time the dataset grows - say so, do not report it as fine; (3) same role and a batch already exceeds it, which means KPI runs are being killed now and nobody has looked. Do NOT change statement_timeout on mars_app_runtime to accommodate a batch. That role serves live user requests and 10s is there deliberately. If the batch needs longer the answer is a separate role or a per-session SET, never widening the shared ceiling.