mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
Eli Foster
badc7784e4
statement_timeout only counts time spent executing, so a session that opens a transaction and then stops issuing statements holds its pooled connection -- and every lock it already took -- with nothing for the statement timeout to cancel. That is the same connection-starvation failure the other two limits close, reached a different way. Set idle_in_transaction_session_timeout alongside them, defaulting to 60s: the budget covers only the gaps between a transaction's statements, so continuous work is never at risk. The three limits move into a RuntimeTimeouts struct rather than growing apply_runtime_connection_timeouts to three same-typed arguments, where a swapped pair would be a silent misconfiguration. Migration exemption assertions now iterate every GUC the applier sets, so a fourth limit added without a matching exemption fails the test. The armed-pool assertions compare milliseconds read from pg_settings instead of SHOW text: Postgres re-spells settings on the way out (60s reads back as 1min), which coupled the test to server formatting. Signed-off-by: Eli Foster <efoster@squareup.com>