3 ms·
Author here. We thought about using statement_timeout, but we didn't like the lack of flexibility when we do have long-running queries that aren't necessarily d
by greenleafjacob 11y ago
Author here. We thought about using statement_timeout, but we didn't like the lack of flexibility when we do have long-running queries that aren't necessarily deleterious to performance. Instead we opted to use two different users ("cron" for long running jobs, and a normal read/write user pair for normal) that the long query killer script will kill at different timeouts, effectively implementing a per-user timeout rather than a global timeout.
I bet the best approach might be to have the statement_timeout be the largest of all of your per-user timeouts (in case your watchdog script fails, can't connect, etc. for whatever reason).
- nickpsecurity 11y agoClever hack.
- e12e 11y agoI've not tried it, but according to PostgreSQL documentation, this should be possible (and recommended) to set on a per role basis? > The ALTER ROLE command allows both global and per-database settings to be overridden with user-specific values. (...) > The SET command allows modification of the current value of those parameters that can be set locally to a session; it has no effect on other sessions. The corresponding function is set_config(setting_name, new_value, is_local). (...) > Setting statement_timeout in postgresql.conf is not recommended because it would affect all sessions.