Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date
Msg-id 20130802204824.GG2706@tamriel.snowman.net
Whole thread Raw
In response to 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>)
Responses Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Greg Smith <greg@2ndQuadrant.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Kudos for Reviewers -- wrapping it up
Next
From: Bruce Momjian
Date:
Subject: Re: Kudos for Reviewers -- wrapping it up