On Wed, 28 Oct 2009, Alvaro Herrera wrote:
> Huh, isn't this code in initdb.c already?
The sketched out design I have for a contrib/pgtune in C presumes that I'd
start by refactoring the relevant bits from initdb into a library for both
programs to use. But the initdb code doesn't care about preserving
existing values when making changes to them; it just throws in its new
settings and moves along. So what's there already only handles about half
the annoying parts most people would expect a tuning tool that reads the
existing file and operates on it to do.
Also, I wouldn't be surprised to find that it chokes on some real-world
postgresql.conf files. The postgresql.conf.sample it's being fed is
fairly pristine. A tuning tool that intends to read any postgresql.conf
it's fed can't always assume it's in exactly standard form. I've recently
started collecting complicated postgresql.conf lines that crashed my
Python code as people submit bug reports with those. You might be
surprised at all of the places people put whitespace at.
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-10-28 16:26:28|
|Subject: Re: Parsing config files in a directory |
|Previous:||From: Tom Lane||Date: 2009-10-28 15:22:36|
|Subject: FOR UPDATE versus outer joins|