pgsql: Raise maximum value of several timeout parameters

Raise maximum value of several timeout parameters

The maximum value of deadlock_timeout, max_standby_archive_delay,
max_standby_streaming_delay, log_min_duration_statement, and
log_autovacuum_min_duration was INT_MAX/1000 milliseconds, which is
about 35min, which is too short for some practical uses. Raise the
maximum value to INT_MAX; the code that uses the parameters already
supports that just fine.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/8c0a5eb78af00ec4720e693feaba70b5a73205d1

Modified Files
--------------
src/backend/utils/misc/guc.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)

On 03/17/2011 02:25 PM, Peter Eisentraut wrote:
> Raise maximum value of several timeout parameters
>
> The maximum value of deadlock_timeout, max_standby_archive_delay,
> max_standby_streaming_delay, log_min_duration_statement, and
> log_autovacuum_min_duration was INT_MAX/1000 milliseconds, which is
> about 35min, which is too short for some practical uses. Raise the
> maximum value to INT_MAX; the code that uses the parameters already
> supports that just fine.
>
>

Did we not intend to backpatch this? The max_standby_*_delay settings
are particularly worrisome to me, and ISTM there's a good case for
calling these just bugs. Surely nobody is relying on the maximum value
being 35 minutes.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 03/17/2011 02:25 PM, Peter Eisentraut wrote:
>> Raise maximum value of several timeout parameters

> Did we not intend to backpatch this? The max_standby_*_delay settings
> are particularly worrisome to me, and ISTM there's a good case for
> calling these just bugs. Surely nobody is relying on the maximum value
> being 35 minutes.

I would argue that this isn't a bug fix: the code was operating as
designed. What it is is a feature improvement, and one that has nonzero
risk of introducing new bugs. So I vote for no backpatch. Let it make
its way into the world after a beta cycle.

regards, tom lane

On Sat, Mar 19, 2011 at 01:43, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 03/17/2011 02:25 PM, Peter Eisentraut wrote:
>>> Raise maximum value of several timeout parameters
>
>> Did we not intend to backpatch this? The max_standby_*_delay settings
>> are particularly worrisome to me, and ISTM there's a good case for
>> calling these just bugs. Surely nobody is relying on the maximum value
>> being 35 minutes.
>
> I would argue that this isn't a bug fix: the code was operating as
> designed.  What it is is a feature improvement, and one that has nonzero
> risk of introducing new bugs.  So I vote for no backpatch.  Let it make
> its way into the world after a beta cycle.

I dunno, I think particularly for the standby delay parameters it can
definitely be considered a bugfix. I've come across a fair number of
cases hitting the current limit right away. And given how trivial the
patch is...

That said, we can have it run through the beta cycle on 9.1 and then
backpatch it after we know it didn't cause any problems there,
perhaps...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/