Re: pgsql: Raise maximum value of several timeout parameters

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Raise maximum value of several timeout parameters
Date: 2011-03-19 13:00:53
Message-ID: AANLkTin1hfG4Y5mYouJva+9REqBHgBYLkSfwaJoEpuRC@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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/

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2011-03-19 14:03:37 Re: pgsql: Document the all-balls IPv6 address.
Previous Message Dave Page 2011-03-19 07:08:06 Re: pgsql: Document the all-balls IPv6 address.