* David Johnston ([email protected]) 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
signature.asc
Description: Digital signature
