Jeff,
* Jeff Janes (jeff.janes@gmail.com) wrote:
> On Thu, Mar 23, 2017 at 1:45 PM, Peter Eisentraut <
> peter.eisentraut@2ndquadrant.com> wrote:
> > On 3/22/17 17:33, David Steele wrote:
> > > and I doubt that most tool writers would be quick to
> > > add support for a feature that very few people (if any) use.
> >
> > I'm not one of those tool writers, although I have written my share of
> > DBA scripts over the years, but I wonder why those tools would really
> > care. They are handed files with predetermined names to archive, and
> > for restore files with predetermined names are requested back from them.
> > What else do they need? If something is missing that requires them to
> > parse file names, then maybe that should be added.
>
> I have a pg_restore which predicts the file 5 files ahead of the one it was
> asked for, and initiates a pre-fetch and decompression of it. Then it
> delivers the file it was asked for, either by pulling it out of the
> pre-staging area set up by the N-5th invocation, or by going directly to
> the archive to get it. This speeds up play-back dramatically when the
> files are stored compressed and non-local.
Ah, yes, that is on our road-map for pgBackrest to do also, along with
parallel WAL fetch which also needs to figure out the WAL names before
being asked for them.
We do already have parallel push, which also needs to figure out what
the upcoming file names are going to be so we can find them and push
them when they're indicated as ready in archive_status. Perhaps we
could just push whatever is ready and remember everything that was
pushed for when PG asks, but that is really not ideal.
> That is why I need to know how the files are numbered. I don't think that
> that makes much of a difference, though. Any change is going to break
> that, no matter which change. Then I'll fix it.
Right, but the discussion here is actually about the idea that we're
going to encourage people to use the initdb-time option to change the
WAL size, meaning you'll need to deal with different WAL sizes and
different naming due to that, and then we're going to turn around in the
very next release and break the naming, meaning you'll have to adjust
your tools first for the different possible WAL sizes in PG10 and then
adjust again for the different naming in PG11.
I'm trying to suggest that if we're going to do this that, perhaps, we
should try to make both the changes in one release instead of across
two.
> If we are going to break it, I'd prefer to just do away with the 'segment'
> thing altogether. You have timelines, and you have files. That's it.
I'm not sure I follow this proposal. We have to know which WAL file has
which LSN in it, how do you do that with just 'timelines and files'?
Thanks!
Stephen
