Re: why is max standby delay only 35 minutes?

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.