On 3/21/17 9:04 AM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Mon, Mar 20, 2017 at 7:23 PM, David Steele <david@pgmasters.net> wrote:
>>> With 16MB WAL segments the filename neatly aligns with the LSN. For
>>> example:
>>>
>>> WAL FILE 0000000100000001000000FE = LSN 1/FE000000
>>>
>>> This no longer holds true with this patch.
>>
>> It is already possible to change the WAL segment size using the
>> configure option --with-wal-segsize, and I think the patch should be
>> consistent with whatever that existing option does.
>
> Considering how little usage that option has likely seen (I can't say
> I've ever run into usage of it so far...), I'm not really sure that it
> makes sense to treat it as final when we're talking about changing the
> default here.
+1. A seldom-used compile-time option does not necessarily provide a
good model for a user-facing feature.
> In short, I'm also concerned about this change to make WAL file names no
> longer match up with LSNs and also about the odd stepping that you get
> as a result of this change when it comes to WAL file names.
I can't decide which way I like best. I like the filenames
corresponding to LSNs as they do now, but it seems like a straight
sequence might be easier to understand. Either way you need to know
that different segment sizes mean different numbers of segments per
lsn.xlogid.
Even now the correspondence is a bit tenuous. I've always thought:
00000001000000010000000F
Should be:
00000001000000010F000000
I'm really excited to (hopefully) have this feature in v10. I just want
to be sure we discuss this as it will be a big change for tool authors
and just about anybody who looks at WAL.
Thanks,
--
-David
david@pgmasters.net
