Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Mar 22, 2017 at 1:49 PM, Stephen Frost <sfr...@snowman.net> wrote: > > Then perhaps we do need to be thinking of moving this to PG11 instead of > > exposing an option that users will start to use which will result in WAL > > naming that'll be confusing and inconsistent. I certainly don't think > > it's a good idea to move forward exposing an option with a naming scheme > > that's agreed to be bad. > > I'm not sure there is any such agreement. I agree that the naming > scheme for WAL files probably isn't the greatest and that David's > proposal is probably better, but we've had that naming scheme for many > years, and I don't accept that making a previously-configure-time > option initdb-time means that it's suddenly necessary to break > everything for people who continue to use a 16MB WAL size.
Apologies, I completely forgot to bring up how the discussion has evolved regarding the 16MB case even though we had moved past it in my head. Let me try to set that right here. One of the reasons to go with the LSN is that we would actually be maintaining what happens when the WAL files are 16MB in size. 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). David had offered up another idea which would change the WAL naming for all sizes, but he and I chatted about it and it seemed like it'd make more sense to maintain the 16MB filenames and then to use the LSN for other sizes also in the same manner. Regardless of which approach we end up using, I do think we need a formal function for converting WAL file names into LSNs and documentation included which spells out exactly how that's done. This is obviously important to backup tools which need to make sure that there aren't any gaps in the WAL stream and also need to figure out where the LSN returned by pg_start_backup() is. We have a function for the latter already, but no documentation explaining how it works, which I believe we should as tool authors need to implement this in their own code since they can't always assume access to a PG server is available. Thanks! Stephen
signature.asc
Description: Digital signature
