[greenleafjacob]

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).

[e12e]

I'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.

[nickpsecurity]

Clever hack.