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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
