On 3/22/17 15:09, Stephen Frost wrote:
> David's initial expectation was this for 64MB WAL files:
>
> 000000010000000000000040
> 000000010000000000000080
> 0000000100000000000000CO
> 000000010000000100000000
>
> Which both matches the LSN *and* keeps the file names the same when
> they're 16MB. This is what David's looking at writing a patch for and
> is what I think we should be considering. This avoids breaking
> compatibility for people who choose to continue using 16MB (assuming
> we switch the default to 64MB, which I am still hopeful we will do).
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.
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.
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
