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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
