I looked through this, and it appears that we can just remove these
restrictions.
I considered the following parameters, which are measured in
milliseconds and currently have INT_MAX/1000 as maximum value.
deadlock_timeout
max_standby_archive_delay
max_standby_streaming_delay
log_min_duration_statement
log_autovacuum_min_duration
In addition there are
autovacuum_naptime
wal_receiver_status_interval
which are measured in seconds and have INT_MAX/1000 as maximum value.
This means they are not proposed to be changed, but they effectively use
the same arithmetic as some of the above parameters after multiplying
their value by 1000, showing that the arithmetic is expected to work up
to INT_MAX.
Also there is
statement_timeout
which is measured in milliseconds and already has INT_MAX as maximum,
and larger values are well exercised here.
Now,
The logic behind deadlock_timeout, max_standby_archive_delay,
max_standby_streaming_delay all depends on TimestampTzPlusMillisecond(),
which is also used by statement_timeout, so it works with values above
INT_MAX/1000. I tried this out with a patched server with
deadlock_timeout, and it works as expected.
log_min_duration_statement has custom code in postgres.c, which is
easily verified to work with values above INT_MAX/1000.
log_autovacuum_min_duration depends on TimestampDifferenceExceeds(),
which is also safe for large values, considering that it is part of the
core timestamp type support.
Consequently, I propose the attached patch. I didn't find any relevant
documentation references that would need updating.
