Re: disabling log_rotation_age feature.
От | Tom Lane |
---|---|
Тема | Re: disabling log_rotation_age feature. |
Дата | |
Msg-id | 6280.1402593934@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: disabling log_rotation_age feature. (David Johnston <david.g.johnston@gmail.com>) |
Список | pgsql-docs |
David Johnston <david.g.johnston@gmail.com> writes: > On Thursday, June 12, 2014, Tom Lane <tgl@sss.pgh.pa.us> 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
В списке pgsql-docs по дате отправления: