Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wv8kw-0006jy-Er for pgsql-docs@arkaria.postgresql.org; Thu, 12 Jun 2014 17:25:42 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wv8kv-0004k1-4s for pgsql-docs@arkaria.postgresql.org; Thu, 12 Jun 2014 17:25:41 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Wv8kt-0004hO-VA for pgsql-docs@postgresql.org; Thu, 12 Jun 2014 17:25:40 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Wv8kq-0003hY-Ub for pgsql-docs@postgresql.org; Thu, 12 Jun 2014 17:25:37 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s5CHPYoA006281; Thu, 12 Jun 2014 13:25:34 -0400 From: Tom Lane To: David Johnston cc: "pgsql-docs@postgresql.org" Subject: Re: disabling log_rotation_age feature. In-reply-to: References: <53992FF8.2060702@po.ntts.co.jp> <23802.1402584095@sss.pgh.pa.us> <26093.1402588800@sss.pgh.pa.us> Comments: In-reply-to David Johnston message dated "Thu, 12 Jun 2014 12:16:07 -0400" Date: Thu, 12 Jun 2014 13:25:34 -0400 Message-ID: <6280.1402593934@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org David Johnston writes: > On Thursday, June 12, 2014, Tom Lane wrote: >> I don't think that argument holds water either. We routinely make >> changes that break old postgresql.conf files. Not in minor updates >> of course, but none of this is material for back-patching. > Then I'd pick throwing an error if a floating point value is assigned to a > parameter that is defined to accept integer. I'd rather actually break the > file and not silently redefine its contents. The case that was under discussion here had nothing to do with float vs integer: it was about rounding a time-interval value to the precision chosen for the underlying variable. That is, if you write "10s" for a variable that's stored in minutes, what should you get? I doubt that "an error" is the best answer here --- one of the purposes of the units system for GUCs was to avoid people having to pay close attention to exactly what the measurement unit of each GUC is. So the realistic answers are "zero minutes" or "1 minute"; and if "zero minutes" is a special case then there's considerable merit in making the value go to "1 minute" instead. Note that right at the moment the behavior is "round down", ie you get zero not 1 minute even if you wrote "59s". I claim that's definitely surprising. regards, tom lane -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs