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: 407d949e0910281220l3a660937ve022fb45aabfc00b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
whack?

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.

--
greg

In response to

Browse pgsql-hackers by date

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