Horton

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 <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Josh Berkus <josh@agliodbs.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Amit Kapila <amit.kapila@huawei.com>, 'Andres Freund' <andres@2ndquadrant.com>, 'Greg Stark' <stark@mit.edu>, 'Alvaro Herrera' <alvherre@2ndquadrant.com>, 'Fujii Masao' <masao.fujii@gmail.com>, 'Robert Haas' <robertmhaas@gmail.com>, 'Dimitri Fontaine' <dimitri@2ndquadrant.fr>, pgsql-hackers@postgresql.org
Date: 2013-08-02T20:48:24Z
Lists: 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