Обсуждение: 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/