* David Johnston (polobo@yahoo.com) wrote:
> How about some form of persistence mechanism so that, before making these
> kinds of changes, the admin can "save" the current configuration. Then, in
> a worse case-scenario, they could run something like "pg_ctl
> --restore-persisted-configuration ..." to reset everything back the last
> known good configuration.
Yeah, I had considered the possibility that we would provide a tool to
manage the config in $PGDATA but I'm not really thrilled with that idea
either.
> A single-version save-restore routine for the configuration. When restoring
> you would want to keep the "current/non-working" configuration and
> associated logging information - maybe archived somewhere along with the a
> copy of the last known working version. This would provide some level of
> audit capability as well as a convenient way for someone to take that
> archive and send it off to someone more knowledgeable for assistance.
> Having it auto-run at boot time - possibly to a different archive area than
> when run manually - would be possible as well; so you'd have both the last
> good boot configuration as well as whatever point-in-time configurations you
> wish to save.
Yeah, there's a lot of work involved in writing a whole system for
managing multiple configurations with history, diffs, etc.. Problems
which, really, our existing text-based config w/ a tool like puppet have
already solved.
Thanks,
Stephen
