On Thu, Apr 7, 2016 at 5:15 AM, Noah Misch <n...@leadboat.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 <n...@leadboat.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/
