Andres Freund-3 wrote
> Even trying to do this completely will guarantee that this patch will
> never, ever, suceed. There simply is no way to reliably detect problems
> that have complex interactions with the rest of the system.
>
> We can improve the detection rate of problems after some real world
> experience. Don't make this unneccesarily complex.
Instead of prevention some thought to recovery should be considered then.
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.
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.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Proposal-for-Allow-postgresql-conf-values-to-be-changed-via-SQL-tp5729917p5765968.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
