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

Re: Parsing config files in a directory

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parsing config files in a directory
Date: 2009-10-27 01:55:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, 26 Oct 2009, Greg Stark wrote:

> When scanning postgresql.conf.d we should follow the Apache/Debian 
> standard of scanning only files which match a single simple hard-coded 
> template. I think the convention is basically the regexp 
> ^[0-9a-zA-Z-]*.conf$. It's important that it exclude typical backup file 
> conventions like foo~ or foo.bak and lock file conventions like .#foo. 
> There's no need for this to be configurable and I think that would be 
> actively harmful.

If the default glob pattern is *.conf, won't all those already be screened 
out?  I can see your point that letting it be adustable will inevitably 
result in some fool one day writing a bad matching pattern that does grab 
backup/lock files.  But is that concern so important that we should limit 
what people who know what they're doing are allowed to do?

That also seems to be the theme of the rest of your comments about how to 
reorganize the postgresql.conf file.  Your comments about what should and 
shouldn't be configurable presumes it's OK for your priorities and what 
you like to be enforced as policy on everyone.  Whether or not I agree 
with you, I object to the idea of dictating in this area because it just 
encourages argument.  The goal here is to add flexibility and ways people 
can choose to work with the configuration, not to replace what's being 
done now outright with an approach everyone must adopt.

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-10-27 03:07:01
Subject: Re: per-tablespace random_page_cost/seq_page_cost
Previous:From: Christophe PettusDate: 2009-10-27 01:35:13
Subject: Re: Proposal: String key space for advisory locks

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