For known slow queries, this would be useful in addition to the automated query killer to limit runtime to <= 60 seconds.

This could also work in the opposite direction, have a global limit that's low, but increase it for known slow queries.

In T293536#7433184, @Legoktm wrote:

For known slow queries, this would be useful in addition to the automated query killer to limit runtime to <= 60 seconds.

This could also work in the opposite direction, have a global limit that's low, but increase it for known slow queries.

I favor this approach, FWIW.

I also think it is reasonable to only set max_statement_time on non-mutating queries (SELECT etc). Catches most of the known bad cases but also means we don't have to worry about violating existing durability guarantees.

FWIW, if I had created this bug, I would have titled it "Mediawiki must send a max_statement_time on every non-mutating database query" :)

Previous: https://phabricator.wikimedia.org/T195792

(I realise this issue is closed, but i just wanted to respond to this suggestion)

In T293536#7433184, @Legoktm wrote:

For known slow queries, this would be useful in addition to the automated query killer to limit runtime to <= 60 seconds.

This could also work in the opposite direction, have a global limit that's low, but increase it for known slow queries.

The issue there is that this global limit would apply to all queries, regardless of user or type of query. Assuming we don't want writes to timeout, all mutating queries would need to be updated to disable the limit. And a lot of dba manual maintenance work would now require the dba to remember to type 'set session.max_statement_limit=0;' at the start of every mysql session.