Thread: Re: Uncommenting .conf WAS: Open items

Bruce, etc:

> If you change shared_buffers to 2000, remove the comment and reload, the
> variable is now 2000.  If you comment out the variable and reload again,
> it is still 2000, not the default.

And more than one person has been baffled and confused by this, including 
several major contributors to our project.   And we discussed this about 2 
months ago and everyone on this list agreed that it should be changed; I'm 
sorry it didn't make it into the TODO at that time.

I see this as a really minor change that will greatly improve the 
comprehension of how to modify the .conf file.   It's documentation, really, 
and we won't be touching any code.   

How about if I tackle this this weekend?   I'd like to double-check the 
organization of the new variables in the file, anyway.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:
> I see this as a really minor change that will greatly improve the 
> comprehension of how to modify the .conf file.   It's documentation, really, 
> and we won't be touching any code.   

Wrong on both counts: it's not really minor (if it were, it would have
got done) and you will need to touch the code.  See the earlier
discussion.  There are several defaults that are presently determined
at compile time and are not correctly reflected into
postgresql.conf.sample.  We'd have to clean that up before we can do
something like this.

Marc's suggestion of just removing all the non-active entries could be
done trivially ;-) ... but I don't think people would see it as an
improvement.
        regards, tom lane

Tom,

> Wrong on both counts: it's not really minor (if it were, it would have
> got done) and you will need to touch the code.  See the earlier
> discussion.  There are several defaults that are presently determined
> at compile time and are not correctly reflected into
> postgresql.conf.sample.  We'd have to clean that up before we can do
> something like this.

I think we can work around that.   Putting those few parameters in as:
#SORT_LOCALE = {set at compile time, check SHOW} 
... would still be an improvement for the *majority* of parameters, which are 
not set at compile time.

-- 
-Josh BerkusAglio Database SolutionsSan Francisco

Josh Berkus <josh@agliodbs.com> writes:
> I think we can work around that.   Putting those few parameters in as:
> #SORT_LOCALE = {set at compile time, check SHOW} 
> ... would still be an improvement for the *majority* of parameters, which are
> not set at compile time.

Okay, if you can live with that grottiness.  But it's still not a
zero-code-touch operation, as at least the sed substitutions in
initdb will need to change.
        regards, tom lane