On Mon, Oct 26, 2009 at 3:30 PM, Josh Berkus <josh@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
