Thread: docs should mention that max_wal_size default depends on WAL segmentsize
Hi, 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. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: docs should mention that max_wal_size default depends on WALsegment size
From
Andres Freund
Date:
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? Greetings, Andres Freund
Re: docs should mention that max_wal_size default depends on WALsegment size
From
Tomas Vondra
Date:
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