On 8/30/17 00:45, Andres Freund wrote:
> 1) Currently the default for {min,max}_wal_size depends on the segment
> size. Given that the segment size is about to be configurable, that
> seems confusing.
On the one hand, I agree that it seems confusing and unnecessary to vary
this with the segment size. On the other hand, the problem is that if
the segment size is larger than the default max_wal_size, we have to do
something different anyway. Also, the reason for wanting a larger
segment size is that you expect a lot of WAL, so setting max_wal_size
larger by default caters to that.
Right now, we have max_wal_size = 1GB by default. What should the
behavior be for wal_segment_size = 1GB?
> 2) Currently wal_segment_size is measured in GUC_UNIT_XBLOCKS, which
> requires us to keep two copies of the underlying variable, one in
> XBLOCKS one in bytes. I'd rather just have the byte variant.
It seems to me that one could structure the code to make do with the
existing variable. I had a brief look at the patch, and I think some
more imaginative refactoring is possible. If we want/need to change it,
I'd prefer using the _KB or _MB variants, so as to not to restrict
future size limits too much.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
