Skip site navigation (1) Skip section navigation (2)

Re: Parsing config files in a directory

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parsing config files in a directory
Date: 2009-10-27 01:22:37
Message-ID: alpine.GSO.2.01.0910262104090.5457@westnet.com (view raw or flat)
Thread:
Lists: 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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

pgsql-hackers by date

Next:From: 노홍찬Date: 2009-10-27 01:32:12
Subject: Re: a question about relkind of RelationData handed over to heap_update function
Previous:From: Gokulakannan SomasundaramDate: 2009-10-27 01:21:51
Subject: A small bug in gram.y

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group