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@dunslane.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@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.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/