On Mon, Oct 26, 2009 at 3:30 PM, Josh Berkus <j...@agliodbs.com> wrote: > Greg, > >> This actually seems like a bad idea to me. > > You write your tool your way, I'll write my tool mine. We'll see which > one works the best in the field.
Yeah actually I meant to but YMMV on that comment and forgot. > >> Well you're assuming there's only one tool generating this config? We >> have at least two and possibly more. initdb generates an initial set >> of defaults, the user may well run some kind of autotuning program, >> and then they also have variables set by SET PERSISTENT. That's three >> pieces of configuration being edited by different pieces of software. > > Well, that's what I'd call a bad idea. Mixing external autotuner which > writes to files with SET PERSISTENT? Well you'll need a story for that. You can't stop users from doing SET PERSISTENT and you'll probably want to adjust some of the variables that initdb sets up too. I'm thinking a typical postgresql.d directory would contain 00initdb.conf 50autotuner.conf 99persistent.conf And also of course read postgresql.conf for any manual settings. When you run autotuner you could either check if any variables have a source which comes after 50autotuner.conf and take them into account or just dump your settings into 50autotuner.conf and then give a warning if any of them are overridden. Likewise I would expect SET PERSISTENT to check if any variables have a source which comes later than 99persistent.conf (namely postgresql.conf normally) and give a warning. (but still dump the variable into the 99persistent.conf file) -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
