Re: [HACKERS] increasing the default WAL segment size
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] increasing the default WAL segment size |
Дата | |
Msg-id | 20170322200900.GA9812@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] increasing the default WAL segment size (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Список | 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 по дате отправления: