Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wv9cO-0008TM-Uz for pgsql-docs@arkaria.postgresql.org; Thu, 12 Jun 2014 18:20:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wv9cO-0007mQ-DK for pgsql-docs@arkaria.postgresql.org; Thu, 12 Jun 2014 18:20:56 +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 1Wv9cN-0007mI-Eg for pgsql-docs@postgresql.org; Thu, 12 Jun 2014 18:20:55 +0000 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Wv9cJ-0004jX-T4 for pgsql-docs@postgresql.org; Thu, 12 Jun 2014 18:20:53 +0000 Received: by mail-we0-f170.google.com with SMTP id w61so1747497wes.15 for ; Thu, 12 Jun 2014 11:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/wha/LvDTC05Gtij2RdG1E1nsgmDeRbJhZ95lHXucHM=; b=Vr8qq9Ovn0s5Pcd9S+NsBk465c869hykYEIOjwBCqNQg7PxsyvMwiLA9c5xqpp5xut H6wOo5BXTajkZFCbtWg8OXELv1aYBoPA0csHEz5UB08ArbPa3hYdA9jLMYt28b/uxZai PWhjxheYkcxySBa35XqQ2cxKGjV3iLDjBAlKzfAznHbIoGd7IrMF0jdKRlPn4dQXxtoR XY9GtC4Xw6yXzqbcXwEAqajwkxPMkrqeZx7KGga6IH8ydfwToVjJIktEhVShVJyZ7hKG BVg4C8yFWXaIVTZseucW3OuPSwTBmUFF/5tBfQCU2EIkUrbQHK7bhw/4YDM8YROfIHWG tcWg== MIME-Version: 1.0 X-Received: by 10.180.88.129 with SMTP id bg1mr8713537wib.51.1402597248525; Thu, 12 Jun 2014 11:20:48 -0700 (PDT) Received: by 10.217.1.145 with HTTP; Thu, 12 Jun 2014 11:20:48 -0700 (PDT) In-Reply-To: References: <53992FF8.2060702@po.ntts.co.jp> <23802.1402584095@sss.pgh.pa.us> <26093.1402588800@sss.pgh.pa.us> <6280.1402593934@sss.pgh.pa.us> Date: Thu, 12 Jun 2014 14:20:48 -0400 Message-ID: Subject: Re: disabling log_rotation_age feature. From: David Johnston To: pgsql-docs@postgresql.org Content-Type: multipart/alternative; boundary=f46d04426c46c31b4504fba79ed7 X-Pg-Spam-Score: -2.0 (--) 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 --f46d04426c46c31b4504fba79ed7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable forgot the list... On Thu, Jun 12, 2014 at 2:05 PM, David Johnston wrote: > On Thu, Jun 12, 2014 at 1:25 PM, Tom Lane wrote: > >> 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. > > > =E2=80=8BI get that: if I request "30s" I get a result of 0.5 - which is = then > truncated=E2=80=8B to zero; "90s" =3D 1.5 -> 1 > > That is, if you write "10s" for >> a variable that's stored in minutes, what should you get? > > > =E2=80=8B0.166667 > > >> I doubt that >> "an error" is the best answer here > > > =E2=80=8BIf we cannot honor the exact value requested telling that to the= user is > definitely a valid outcome=E2=80=8B > > >> --- 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. > > > =E2=80=8BAnd if their desired value falls into the expected range of allo= wed > values =E2=80=8Bthen they can remain oblivious. But if they want to do s= omething > that the system is incapable of supporting forcing them to explicitly cho= se > a different value is just as valid a decision as picking one for them. > > =E2=80=8BRestricting that to scaling up - which is what happens in realit= y anyway > - means that at least whatever the user tells the system is either what > they get or they are told their request is invalid. > > The likelihood of someone requesting "120s" when they desire "2m" is > unlikely - I would think that most typically they would be requesting a > number of, in this case, seconds that are less than the default unit=E2= =80=8B, 1 > minute in this case. > > If it only errors when the final result is zero I would not be overly > opposed to situations like "90s" rounding to "2m" instead of "1m". > > >> 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. >> > > Another supporting argument is that the risk profile for anyone depending > on a non-explicit zero to obtain zero behavior =E2=80=8Bis small - if the= y changed > from default and were checking to make sure the final result matched thei= r > expectation they would see the relevant difference. The OP complaint > indeed is "I thought I enabled this but it didn't work". > > I am somewhat concerned about, say "100m" rounding to 2 hours instead of = 1 > hour. The minute/second rounding is fairly small but for larger unit-pai= rs > the amount of delta before and after can be considerable. But there may = be > few, if any, parameters that could be so affected so probably a moot > concern. > > >> 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. >> >> > =E2=80=8BAs is rounding "70s" up to "2m" > > In both cases since we are taking invalid data and substituting valid dat= a > we have to document what is being done. Its just the probability of > someone realizing and caring about what we are doing is smaller if we use > ceiling instead of floor. > > While I am generally in favor of requiring explicitness there is minimal > downside risk in leaving "implicit casting" of the data in this context. > Given that conclusion, making the change to ceiling from floor makes sen= se > - making it possible to only achieve zero explicitly is worthwhile. For a= ll > non-zero situations the direction of rounding is largely immaterial if yo= u > accept that rounding has value. > > David J. > > --f46d04426c46c31b4504fba79ed7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
forgot the list...

On T= hu, Jun 12, 2014 at 2:05 PM, David Johnston <david.g.johnston@gmail.com> wrote:
On Thu, Jun 12, 2014 at 1:25 PM, Tom Lane= <tgl@sss.pgh.pa.us> wrote:
David Johnston <david.g.johnston@gmail.c= om> writes:
> On Thursday, June 12, 2014, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't think that argument holds water either. =C2= =A0We routinely make
>> changes that break old postgresql.conf files. =C2=A0Not in minor u= pdates
>> of course, but none of this is material for back-patching.

> Then I'd pick throwing an error if a floating point value is assig= ned to a
> parameter that is defined to accept integer. I'd rather actually b= reak 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. =C2=A0

=E2=80=8BI get = that: if I request "30s" I get a result of 0.5 - which is then tr= uncated=E2=80=8B to zero; "90s" =3D 1.5 -> 1

That is, if you write &= quot;10s" for
a variable that's stored in minutes, what should you get? =C2=A0

=E2=80=8B0.166667
=C2=A0
I doubt that
"an error" is the best answer here

=E2=80=8BIf we can= not honor the exact value requested telling that to the user is definitely = a valid outcome=E2=80=8B
=C2=A0
--- one of the purpos= es 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. =C2=A0
<= br>
=E2=80=8BAnd= if their desired value falls into the expected range of allowed values =E2= =80=8Bthen they can remain oblivious. =C2=A0But if they want to do somethin= g that the system is incapable of supporting forcing them to explicitly cho= se a different value is just as valid a decision as picking one for them.

= =E2=80=8BRestricting that to scaling up - which is what happens in reality = anyway - means that at least whatever the user tells the system is either w= hat they get or they are told their request is invalid.

The likelihood of someone reque= sting "120s" when they desire "2m" is unlikely - I woul= d think that most typically they would be requesting a number of, in this c= ase, seconds that are less than the default unit=E2=80=8B, 1 minute in this= case.

If it only errors when the fina= l result is zero I would not be overly opposed to situations like "90s= " rounding to "2m" instead of "1m".
=C2=A0
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<= br> "1 minute" instead.

Another supporting argument is= that the risk profile for anyone depending on a non-explicit zero to obtai= n zero behavior =E2=80=8Bis small - if they changed from default and were c= hecking to make sure the final result matched their expectation they would = see the relevant difference. =C2=A0The OP complaint indeed is "I thoug= ht I enabled this but it didn't work".

I am somewhat concerned ab= out, say "100m" rounding to 2 hours instead of 1 hour. =C2=A0The = minute/second rounding is fairly small but for larger unit-pairs the amount= of delta before and after can be considerable. =C2=A0But there may be few,= if any, parameters that could be so affected so probably a moot concern.


Note that right at the moment the behavior is "round down", ie yo= u get
zero not 1 minute even if you wrote "59s". =C2=A0I claim that'= ;s definitely
surprising.


=E2=80=8BAs is rounding "70s" up to &qu= ot;2m"

In both cas= es since we are taking invalid data and substituting valid data we have to = document what is being done. =C2=A0Its just =C2=A0the probability of someon= e realizing and caring about what we are doing is smaller if we use ceiling= instead of floor.

While I am generally in favor o= f requiring explicitness there is minimal downside risk in leaving "im= plicit casting" of the data in this context. =C2=A0Given that conclusi= on, making the change to ceiling from floor makes sense - making it possibl= e to only achieve zero explicitly is worthwhile. For all non-zero situation= s the direction of rounding is largely immaterial if you accept that roundi= ng has value.

David J.

<= /div>

--f46d04426c46c31b4504fba79ed7--