Re: Parsing config files in a directory - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Parsing config files in a directory
Date
Msg-id alpine.GSO.2.01.0910262104090.5457@westnet.com
Whole thread Raw
In response to Re: Parsing config files in a directory  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Parsing config files in a directory
List pgsql-hackers
On Mon, 26 Oct 2009, Kevin Grittner wrote:

> We do find the include capabilities useful.  For example, for our 72
> production servers for county Circuit Court systems, we copy an
> identical postgresql.conf file to each county, with the last line
> being an include to an overrides conf file in /etc/.  For most
> counties that file is empty.  For counties where we've installed extra
> RAM or where data is not fully cached, we override settings like
> effective_cache_size or the page costs.  I can't see where any of the
> options under discussion would do much to help an environment like
> ours -- they seem more likely to help shops with fewer servers or more
> relaxed deployment procedures.

That's exactly a use case the "parsing config files in a directory" 
feature aims to make easier to manage.  You can just mix and match files 
that adjust a subset of the postgresql.conf without having to explicitly 
include them.  For this sort of situation, you could create a base set of 
configuration changes, then a set that customizes for less common server 
configurations, and possibly even server-specific ones.  Copy in the 
subset from that master list of possible configuration sets that apply to 
this server and you're done.

Since variations on this feedback keep coming up, let's be be clear here: 
there is nothing this patch aims to add you can't already do with include 
files.  It's just a way to make more aggressive use of include files 
easier to manage, and therefore make doing so in the default configuration 
less objectionable.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Gokulakannan Somasundaram
Date:
Subject: A small bug in gram.y
Next
From: Christophe Pettus
Date:
Subject: Re: Proposal: String key space for advisory locks