docs should mention that max_wal_size default depends on WAL segment size

Started by Tomas Vondraabout 7 years ago3 messages
#1Tomas Vondra
tomas.vondra@2ndquadrant.com

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

#2Andres Freund
andres@anarazel.de
In reply to: Tomas Vondra (#1)
Re: docs should mention that max_wal_size default depends on WAL segment size

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

#3Tomas Vondra
tomas.vondra@2ndquadrant.com
In reply to: Andres Freund (#2)
Re: docs should mention that max_wal_size default depends on WAL segment size

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