Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
От | Stephen Frost |
---|---|
Тема | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
Дата | |
Msg-id | 20130802011516.GW2706@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) (David Johnston <polobo@yahoo.com>) |
Список | pgsql-hackers |
* 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
В списке pgsql-hackers по дате отправления: