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 | 20130802204824.GG2706@tamriel.snowman.net обсуждение |
| Ответ на | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: Re: ALTER SYSTEM SET command to change postgresql.conf
parameters (RE: Proposal for Allow postgresql.conf values to be changed via
SQL [review])
|
| Список | pgsql-hackers |
* Josh Berkus (josh@agliodbs.com) wrote:
> I really think this is the wrong approach. If we start removing
> "unsafe" parameters from ALTER SYSTEM SET, we basically hobble the
> feature to the point of uselessness. Out of the 15 or so parameters 80%
> of our users touch, half of them are on your "unsafe" list.
Reflecting on this a bit more, I'm curious what your list-of-15 is.
Many of the items on my list were file locations or other things which
generally require coordination with other groups (like the unix admins
or network admins) to change, eg: listen_addresses, port, SSL or
Kerberos file locations, etc.
There's quite a few parameters which I've changed that are "safe" and
internal-to-PG which weren't on my list- work_mem, maint_work_mem,
vacuum / autovacuum settings, effective_io_concurrency, wal_level,
sync_commit, checkpoint settings, max_wal_senders, planner costs,
logging settings (though this might have to be coordinated w/ the unix
admins unless splunk or similar is being used), etc.
Thanks,
Stephen
В списке pgsql-hackers по дате отправления: