Global non-0 value for `statement_timeout`?

Would it ever be advisable to set statement_timeout to a global non-0 value, ignoring the warning?

Setting statement_timeout in postgresql.conf is not recommended because it would affect all sessions.

My use case is a write-heavy, timeseries, OLTP-only workload - the tables are partitioned by range. And my goal is to set a relatively low global statement_timeout, e.g. 5 s, in order to:

• make long(er)-running maintenance operations (f.e. reindexing) set their per-session statement_timeout.
• make suboptimal queries fail, without affecting the DB (f.e. queries missing the partition key in their WHERE clause). Part of the desire to lower this setting also stems from distrusting the "application" developers. I consider the example 5 s still quite generous.

Gitlab at least considered this, though I don't know if they actually made the change.

1. Is any of the system processes affected by statement_timeout? Autovacuum doesn't seem to be, judging from the source code.
2. Anything else one should watch out for?

It is perfectly safe to set statement_timeout to a non-zero value globally, and I would in fact recommend it. System processes like autovacuum are not affected by that setting.

I normally recommend to set it to a value that is safely above the longest statement that you expect, so if you don't expect statements longer than 10 seconds, 15 minutes might be a good value. But if you don't forget to explicitly set statement_timeout to a higher value in sessions that need it, there is nothing wrong with a limit of five seconds. Just remember that you are ultimately working for a good user experience, and getting an error because a statement took too long isn't a good user experience.