Re: Patch: raise default for max_wal_segments to 1GB

On Tue, Mar 3, 2015 at 4:25 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 03/03/2015 01:43 AM, Andres Freund wrote:
>>
>> On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
>>>
>>> ! #max_wal_size = 1GB # in logfile segments
>>
>>
>> Independent of the rest of the changes, the "in logfile segments" bit
>> should probably be changed.
>
>
> The "base unit" is still logfile segments, so if you write just
> "max_wal_size = 10" without a unit, that means 160MB. That's what the
> comment means.
>
> Is it needed? Many settings have a similar comment, but most don't. Most of
> the ones that do have a magic value 0, -1 as default, so that it's not
> obvious from the default what the unit is. For example:
>
> #tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds;
> # 0 selects the system default
> #tcp_keepalives_interval = 0 # TCP_KEEPINTVL, in seconds;
> # 0 selects the system default
> #temp_file_limit = -1 # limits per-session temp file space
> # in kB, or -1 for no limit
> #commit_delay = 0 # range 0-100000, in microseconds
> #log_temp_files = -1 # log temporary files equal or
> larger
> # than the specified size in
> kilobytes;
> # -1 disables, 0 logs all temp files
> #statement_timeout = 0 # in milliseconds, 0 is disabled
> #lock_timeout = 0 # in milliseconds, 0 is disabled
> #wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
>
> But there are also:
>
> #wal_receiver_timeout = 60s # time that receiver waits for
> # communication from master
> # in milliseconds; 0 disables
> #autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
> # autovacuum, in milliseconds;
> # -1 means use vacuum_cost_delay
>
>
> 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.

Seems OK to me. BTW, we can also remove "in milliseconds" from
wal_sender_timeout.

> (and we should also change wal_keep_segments to accept MB/GB, as discussed
> already)

+1

Regards,

--
Fujii Masao