Re: auto-sizing wal_buffers

Greg Smith <greg@2ndquadrant.com>

From: Greg Smith <greg@2ndquadrant.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Magnus Hagander <magnus@hagander.net>, pgsql-hackers@postgresql.org
Date: 2011-01-15T16:52:52Z
Lists: pgsql-hackers

Attachments

Fujii Masao wrote:
> +int			XLOGbuffersMin = 8;
>
> XLOGbuffersMin is a fixed value. I think that defining it as a macro
> rather than a variable seems better.
>
> +		if (XLOGbuffers > 2048)
> +			XLOGbuffers = 2048;
>
> Using "XLOG_SEG_SIZE/XLOG_BLCKSZ" rather than 2048 seems
> better.
>
> +#wal_buffers = -1			# min 32kB, -1 sets based on shared_buffers
>
> Typo: s/32kB/64kB
>   

Thanks, I've fixed all these issues and attached a new full patch, 
pushed to github, etc.  Tests give same results back, and it's nice that 
it scale to reasonable behavior if someone changes their XLOG segment size.

It should be possible to set the value back to the older minimum value 
of 32kB too.  That's doesn't actually seem to work though; when I try it 
I get:

$ psql -c "SELECT name,unit,boot_val,setting,current_setting(name) FROM 
pg_settings WHERE name IN ('wal_buffers','shared_buffers')"
      name      | unit | boot_val | setting | current_setting
----------------+------+----------+---------+-----------------
 shared_buffers | 8kB  | 1024     | 131072  | 1GB
 wal_buffers    | 8kB  | -1       | 8       | 64kB

Where I was expecting that setting to be "4" instead for 32kB.  So 
there's probably some minor bug left in where I inserted this into the 
initialization sequence.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books