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

Re: Proposal for Allow postgresql.conf values to be changed via SQL

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-11-02 11:17:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Nov 2, 2012 at 2:19 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:

> On 10/31/12 12:17 PM, Magnus Hagander wrote:
>  The idea at the time was to use the include *directory* functionality,
>> for say a "config.d" directory in pgdata. The builtin one would then
>> use a predictable filename in this directory, so that the DBA who
>> prefers it can drop files both before and after that file into the
>> directory.
> That's how I remember things as well.  Unfortunately Amit's proposal seems
> like an even more complicated version of ideas that were clearly beaten
> down multiple times over many years now, partly for being too complicated.
> The only idea I remember ever crossing the gap between the "edit by hand"
> and "tool config" crowd was based on the include directory concept.  The
> bugs in that implementation are finally worked out and the include_dir
> feature committed recently, so now it's possible to consider using it as a
> building block now.
> Here is a much simpler proposal for example:
> -Add a configuration subdirectory to the default installation.  Needs to
> follow the config file location, so things like the Debian relocation of
> postgresql.conf still work.  Maybe it has zero files; maybe it has one
> that's named for this purpose, which defaults to the usual:

What do you mean by "needs to follow"? In particular, do you mean that it
should be relative to postgresql.conf? I think that would actually be a
*problem* for any system that moves the config file away, like debian,
since you'd then have to grant postgres write permissions on a directory in

> # Don't edit this file by hand!  It's overwritten by...
> -Have the standard postgresql.conf end by including that directory
> -SQL parameter changes collect up all other active parameter changes,
> rewrite that file, and signal the server.  If any change requested requires
> a full server restart. warn the user of that fact.
> And that's basically it.  Cranky old-timers can remove the include
> directive and/or directory if they don't like it, act as if nothing has
> changed, and move along.  Everyone else gets the beginning of a multiple
> co-existing tool change standard.
> The only obvious bad case I can think of here is if someone has left the
> directory there, but deleted the include_dir statement; then the file would
> be written successfully but never included.  Seems like in the worst case
> the postgresql.conf parser would just need to flag whether it found the
> default directory included or not, to try and flag avoid obvious foot
> shooting.

Yes. And we could pretty easily find that - have the function that reloads
the config file actually check the source file and line number to make sure
it matches the one fro mthe auto file, and give a WARNING if it doesn't
(which indicates that either the file isn't included, or something else
"later in the chain" overwrote it)

Some of the better received ideas I floated for merging the recovery.conf
> file seemed headed this way too.  That also all blocked behind the include
> directory bit being surprisingly tricky to get committed.  So that's
> possible to revive usefully now.  And as much as I hate to expand scope by
> saying it, both changes should probably be tackled at once.  It's important
> to make sure they're both solved well by whatever is adopted, they are
> going to co-exist as committed one day.

Yeah, we don't need the code for both, but we certainly need a "reasonable
design" capable of dealing with both, so we don't paint ourselves into a

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Pavan DeolaseeDate: 2012-11-02 11:52:07
Previous:From: Alexander KorotkovDate: 2012-11-02 08:54:33
Subject: Re: gistchoose vs. bloat

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