Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Martijn van Oosterhout <kleptog@svana.org>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Dimitri Fontaine <dimitri@2ndquadrant.fr>,
Andres Freund <andres@2ndquadrant.com>,
Josh Berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Fujii Masao <masao.fujii@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2013-08-22T16:04:08Z
Lists: pgsql-hackers
On Thu, Aug 22, 2013 at 08:36:37AM -0400, Stephen Frost wrote: > * Amit Kapila (amit.kapila16@gmail.com) wrote: > > This can resolve the problem of whether to read auto file rather > > cleanly, so the idea is: > > > > Enable/Disable reading of auto file > > ----------------------------------------------------- > > a. Have a new include in postresql.conf > > #include_auto_conf_file postgresql.auto.conf > > as it is a special include, we can read this file relative to data > > directory. The big advantage of using 'include_auto_conf_file' and not simply 'include' is that we can issue an error from ALTER SYSTEM SET if that is not set. > > Enable/Disable Alter System command > > ----------------------------------------------------------- > > This can be achieved in 3 ways: > > a. Check before executing Alter System if include directive is > > disabled, then just issue a warning to user and proceed with command. > > b. Check before executing Alter System if include directive is > > disabled, then just issue an error and stop. > > It doesn't make sense for it to be a 'warning' with this- the > parameter specifies the file to use. If you don't know what file to > use, how you can possibly do anything but return an error? Agreed. No sense in allowing users to add things to the 'auto' file when the auto file is inactive. > Note that I *like* that about this approach. > > There are a few other considerations with this- > > - What should the default be? (Still thinking 'off' myself) Probably, but we might need to wait until we have a final API for a decision on that. > - What happens if the user specifies 'postgresql.conf'? I'm thinking we > would disallow such insanity (as that's what it is, imv..) by having > an identifier in the file that this is the PG "auto conf" file. I am thinking they can't include a value equal to 'config_file', which is normally postgresql.conf. I am not a big fan of looking for special text in files. This might be complex to check, though, because of path changes --- we might just disallow the basement from matching the basename of config_file. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +