On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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. > I apparently have got to make this point one more time: if the user > cares about the difference between 30sec and 1min, then we erred in > designing the GUC in question; it should have had a smaller unit. > I am completely not impressed by arguments based on such cases. > The right fix for such a case is to choose a different unit for the GUC. The guy who wrote the GUC system doesn't seem to agree with you, and neither do I. Changing the unit for log_rotation_age from minutes to seconds doesn't fix the original complaint, which was that a non-zero value like 1s gets rounded down to zero. Even after you change the unit to seconds, you still have the same problem with a specification of 1ms. You could change the log rotation unit to 1ms, but that's silly, and as soon as we get a unit measured in microseconds or nanoseconds, which seems like just a matter of time, you have the same problem again. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
