Re: Updated backup APIs for non-exclusive backups

On Thu, Apr 7, 2016 at 5:15 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:

> On Wed, Apr 06, 2016 at 09:17:22AM +0200, Magnus Hagander wrote:
> > On Wed, Apr 6, 2016 at 6:42 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > On Tue, Apr 05, 2016 at 08:15:16PM +0200, Magnus Hagander wrote:
> > > > I've pushed this version, and also added the item from the Brussels
> > > > developer meeting to actually rewrite the main backup docs to the
> open
> > > > items so they are definitely not forgotten for 9.6.
> > >
> > > Here's that PostgreSQL 9.6 open item:
> > >
> > > * Update of backup documentation (assigned to Bruce at [
> > > https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2016_Developer_Meeting
> > > Brussels Developer Meeting], but others are surely allowed to work on
> it as
> > > well)
> > > ** Made required by 7117685461af50f50c03f43e6a622284c8d54694 since the
> > > current documentation is now incorrect
> > >
> > > Unless Bruce endorsed this development strategy, I think it unfair for
> > > commit
> > > 7117685 to impose a deadline on his backup.sgml project. Did commit
> > > 7117685
> > >
> >
> > I agree that's a horrible wording. What it meant to imply was a deadline
> > for *me* to help take that off Bruce's shoulders before then while also
> > opening the doors for others to work on it should they want. Re-reading
> it
> > now I can see that's not at all what it says. I'll reword (or rather,
> > remove most of that, since it's been discussed separately and doesn't
> > actually need to go on the open items list which is a list and not a
> > discussion)
>
> Ahh. Your original wording did admit your interpretation; I just didn't
> think
> of that interpretation.
>
> > > The chapter already does describe pg_basebackup before describing
> > > pg_start_backup; what else did the plan entail?
>
> > Recommending people to primarily use tried and tested ways of doing
> backups
> > (including a reference to a list, probably on the wiki, of known external
> > tools that "do things the right way", such as backrest or barman) rather
> > than focusing on examples that aren't necessarily even correct, and
> > certainly not complete.
> >
> > Mentioning the actual problems of exclusive base backups. (And obviously
> > talk about how using pg_start_backup/pg_stop_backup now makes it possible
> > to do "low level" backups without the risks of exclusive backups -- which
> > is the "incomplete" part from my note.
> >
> > More clearly outlining backup vs dump, and possibly (I can't actually
> > remember if we decided the second step) put base backups before pg_dump
> > since the topic is backups.
>
> Unless you especially want to self-impose the same tight resolution
> schedule
> that 9.6 regressions experience, let's move this to the "Non-bugs" section.
> Which do you prefer? I don't think the opportunity for more documentation
> in
> light of 7117685 constitutes a regression, and I don't want "Open Issues"
> to
> double as a parking lot for slow-moving non-regressions.
>

Well, if we *don't* do the rewrite before we release it, then we have to
instead put information about the new version of the functions into the old
structure I think.

So I think it's an open issue. But maybe we should have a separate section
on the open items list for documentation issues? I tihnk we've had that
some times before.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/