Re: Patch: raise default for max_wal_segments to 1GB

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.

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

- Heikki