Re: Parsing config files in a directory

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(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-26 14:06:39
Message-ID: 20091026140638.GC8812@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas escribió:
> On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> > It actually makes it completely trivial to implement.  SET PERSISTENT can
> > now write all the changes out to a new file in the include directory. Just
> > ship the database with a persistent.conf in there that looks like this:
>
> This only sorta works. If the changes are written out to a file that
> is processed after postgresql.conf (or some other file that contains
> values for those variables), then someone who edits postgresql.conf
> (or some other file) by hand will think they have changed a setting
> when they really haven't.

Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
automatic comment "# overridden in persistent.conf" and put a comment
marker in front of the original line. That way the user is led to the
actual authoritative source.

> On the flip side, there could also be still
> other files that are processed afterwards, in which case SET
> PERSISTENT would appear to work but not actually do anything.

Fortunately we now have an easy way to find out which file is each
setting's value coming from.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-26 14:07:53 Re: Proposal: String key space for advisory locks
Previous Message Dave Page 2009-10-26 13:51:27 Re: License clarification: BSD vs MIT