On 03/03/2015 10:37 AM, Heikki Linnakangas wrote:
> On 03/03/2015 08:31 PM, Josh Berkus wrote:
>> On 03/03/2015 10:29 AM, Heikki Linnakangas wrote:
>>> On 03/03/2015 08:21 PM, Josh Berkus wrote:
>>>> On 03/03/2015 10:15 AM, Josh Berkus wrote:
>>>>> On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
>>>>>> I propose that we remove the comment from max_wal_size, and also
>>>>>> remove
>>>>>> the "in milliseconds" from wal_receiver_timeout and
>>>>>> autovacuum_vacuum_cost_delay.
>>>>>
>>>>> +1
>>>>>
>>>>
>>>> Actually, let's be consistent about this. It makes no sense to remove
>>>> unit comments from some settings which accept ms but not others.
>>>>
>>>> Do we want to remove unit comments from all settings which accept
>>>> "MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
>>>> this, but seems like (a) it should be universal, and (b) its own patch.
>>>
>>> I think it's a good rule that if the commented-out default in the sample
>>> file does not contain a unit, then the base unit is in the comment.
>>> Otherwise it's not. For example:
>>>
>>> #shared_buffers = 32MB # min 128kB
>>> # (change requires restart)
>>>
>>> The base unit is BLCKSZ, i.e. 8k, but usually people will usually use
>>> MB/GB. And that is evident from the default value, 32MB, so there's no
>>> need to mention it in the comment.
>>>
>>> #tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds;
>>> # 0 selects the system default
>>>
>>> Here it's not obvious what the unit should be from the default itself.
>>> So the comment says it's "in seconds".
>>
>> Sure. Although, do we take (s) for tcp_keepalives_idle? Or only an INT?
>
> It's a "time unit", so you can say "10s" or "10000ms". If you don't
> specify a unit, it implies seconds.
So if we're going to make this consistent, let's make it consistent.
1. All GUCs which accept time/size units will have them on the default
setting.
2. Time/size comments will be removed, *except* from GUCs which do not
accept (ms/s/min) or (kB/MB/GB).
Argument for: the current inconsistency confuses new users and his
entirely historical in nature.
Argument Against: will create unnecessary diff changes between 9.4's
pg.conf and 9.5's pg.conf.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com