On 11/18/18 10:22 PM, Andres Freund wrote:
> Hi,
>
> On 2018-11-18 22:16:12 +0100, Tomas Vondra wrote:
>> while investigating something on a cluster with a non-default WAL
>> segment (say 256MB), I've noticed a somewhat surprising behavior of
>> max_wal_size default. While the docs claim the default is 1GB, the
>> actual default depends on the WAL segment size.
>>
>> For example with the 256MB WAL segments, you end up with this:
>>
>> test=# show max_wal_size ;
>> max_wal_size
>> --------------
>> 16GB
>> (1 row)
>>
>> This behavior is not entirely new - I've noticed it on 10, before the
>> WAL segment size was moved to initdb (which made it more likely to be
>> used). It's even more surprising there, because it leaves
>>
>> #max_wal_size = 1GB
>>
>> in the sample config, while fc49e24f at least emits the actual value.
>>
>> But I'd say not mentioning this behavior in the docs is a bug.
>
> Hm, you're not wrong there. Wonder if it'd be better to make it so that
> the default actually has the effect of being 1GB - I think that ought to
> be doable?
>
I've actually thought about that, initially, but I'm not sure that's a
good idea for a couple of reasons:
(1) WAL segments can go up to 1GB now, and we need at least two of
those, so there are at least some cases where we can't stick to the 1GB
max_wal_size default.
(2) If you're messing with WAL segment size, chances are you either have
very large/busy or very small system, and so the changes to max_wal_size
probably make sense.
(3) If we decide to enforce the 1GB default, we should probably
backpatch it, otherwise you'll get surprisingly different behavior on
different versions. Not great. But backpatching may influence existing
systems quite a bit. Of course, there are probably few systems tweaking
WAL segment size, and I'd expect them to set max_wal_size explicitly
(rendering the default irrelevant).
So, not sure.
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services