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