Re: [HACKERS] increasing the default WAL segment size - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] increasing the default WAL segment size
Date
Msg-id 20170322200900.GA9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] increasing the default WAL segment size  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> The question is, which property is more useful to preserve: matching
> LSN, or having a mostly consecutive numbering.
>
> Actually, I would really really like to have both, but if I had to pick
> one, I'd lean 55% toward consecutive numbering.

> For the issue at hand, I think it's fine to proceed with the naming
> schema that the existing compile-time option gives you.

What I don't particularly like about that is that it's *not* actually
consecutive, you end up with this:

000000010000000000000001
000000010000000000000002
000000010000000000000003
000000010000000100000000

Which is part of what I don't particularly like about this approach.

> In fact, that would flush out some of the tools that look directly at
> the file names and interpret them, thus preserving the option to move to
> a more radically different format.

This doesn't make a lot of sense to me.  If we get people to change to
using larger WAL segments and the tools are modified to understand the
pseudo-consecutive format, and then you want to change it on them again
in another release or two?  I'm generally a fan of not feeling too bad
breaking backwards compatibility, but it seems pretty rough even to me
to do so immediately.

This is exactly why I think it'd be better to work out a good naming
scheme now that actually makes sense and that we'll be able to stick
with for a while instead of rushing to get this ability in now, when
we'll have people actually starting to use it and then try to change it.

> If changing WAL sizes catches on, I do think we should keep thinking
> about a new format for a future release, because debugging will
> otherwise become a bit wild.  I'm thinking something like
>
>     {integer timeline}_{integer seq number}_{hex lsn}
>
> might address various interests.

Right, I'd rather not have debugging WAL files become a bit wild.

If we can't work out a sensible approach to naming that we expect to
last us for at least a couple of releases for different sizes of WAL
files, then I don't think we should rush to encourage users to use
different sizes of WAL files.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUCpseudo-variable.
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.