From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Beena Emerson <memissemerson(at)gmail(dot)com>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: increasing the default WAL segment size |
Date: | 2017-03-22 20:09:00 |
Message-ID: | 20170322200900.GA9812@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-03-22 20:28:18 | Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. |
Previous Message | Peter Eisentraut | 2017-03-22 20:00:14 | Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. |