Re: proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 2:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> If we want the narrowest possible fix for this, I think it's "complain
> >> if a non-zero value would round to zero". That fixes the original
> >> complaint and changes absolutely nothing else. But I think that's
> >> kind of wussy. Yeah, rounding 29 seconds down to a special magic
> >> value of 0 is more surprising than rounding 30 seconds up to a minute,
> >> but the latter is still surprising. We're generally not averse to
> >> tighter validation, so why here?
> >
> > So in other words, if I set "shared_buffers = 100KB", you are proposing
> > that that be rejected because it's not an exact multiple of 8KB?
>
> Absolutely. And if anyone is inconvenienced by that, then they should
> upgrade to a 386. Seriously, who is going to set a value of
> shared_buffers that is not measured in MB? And if they do, why
> shouldn't we complain if we can't honor the value exactly? If they
> really put in a value that small, it's not stupid to think that the
> difference between 96kB and 104kB is significant. Honestly, the most
> likely explanation for that value is that it's a developer doing
> testing.
>

​Related
thought - why don't we allow the user to specify "1.5MB" as a valid value?
​ Since we don't the rounding on the 8kb stuff makes sense because not
everyone wants to choose between 1MB and 2MB. A difference of 1 minute is
not as noticeable.​

In the thread Tom linked to earlier the whole idea of a unit being "8kb"
(instead "1 block") is problematic and this is just another symptom of that.

David J.