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

Re: Parsing config files in a directory

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parsing config files in a directory
Date: 2009-10-28 19:20:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Oct 28, 2009 at 12:08 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Perhaps the ease of writing something like that with sed or perl has
>> caused me to underestimate the effort required in C.  I am curious
>> whether you actually mean that, or said it for rhetorical effect.
> I actually mean that.  It *looks* easy in perl, and in fact *is* easy
> for *your* postgresql.conf which you control.  But writing a parser for
> every postgresql.conf which exists in the world, no matter how someone
> has hacked it up creatively?  No matter how they've handled upgrades?
> For every version of PostgreSQL?  That requires writing a full parser
> with grammar and near-turing capabilities.

I think we're getting distracted by the basic parsing questions. These
are actually solvable -- pgadmin solves them today even.

I think the bigger problem is the semantic questions. If I've lowered
random_page_cost and your tool decides it should raise
sequential_page_cost should it raise random_page_cost proportionally
from my setting or to the absolute value it calculates? When it does
will I be annoyed to see my settings overwritten? What if I set some
of the cpu_* parameters based on my random_page_cost setting and now
that you've overwritten my random_page_cost setting they're all out of

And not all programs editing these files will be equally intelligent.
Say I post a snippet of configuration and say to drop it in wholesale
into your postgresql.conf.d. Then the user runs autotune which drops a
configuration in after it which overrides those settings. Then later I
post an updated snippet and the user replaces the original snippet. If
they're in separate files and he put the snippet in before the
autotune configuration then he doesn't have to worry if the new
snippet contains things which autotune overrode. They'll still
override the new settings.

If you keep them separate then the actual settings may not be in sync
but at least I can see each group of settings and understand what they
were trying to do.  The precedence remains the same. It also means the
database could give warnings if files are overriding earlier files if
we want that.


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-10-28 19:28:09
Subject: Re: Parsing config files in a directory
Previous:From: Hannu KrosingDate: 2009-10-28 19:09:40
Subject: Re: [PATCHES] updated hash functions for postgresql v1

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