Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date
Msg-id 5145E9E3.7090200@2ndQuadrant.com
Whole thread Raw
In response to Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
On 3/14/13 4:48 PM, Boszormenyi Zoltan wrote:
> The attached patch makes
> SET PERSISTENT transactional and uses one setting per file.
> It uses the currently existing parsing and validating code
> and because of this, the patch is half the size of v12 from Amit.

That's not a completely fair comparison, because you lost all the 
regression testing code too.  This does look like a usefully tighter 
implementation in a few ways, so good progress on that.

I still can't see any reason to prefer this "one setting per file" idea.  As I see it, that is pushing the complexity
towardthe user in a bad 
 
way, seemingly just so it's easier to implement.  Most of my customers 
now use tools like Puppet to manage their PostgreSQL configuration.  I 
do not want to have this conversation:

Greg:  "You can use SET PERSISTENT to modify settings instead of 
changing the postgresql.conf"

User:  "That's useful.  How do we adjust Puppet to make sure it picks up 
the changes?"

Greg:  "You just scan this config directory and add every file that 
appears in there!  Each setting will be in its own file."

User:  "<shocked look>  It creates new files?  That isn't going to fit 
into our version control approach easily.  Can we disable this feature 
so no one accidentally uses it?"

I'm not exaggerating here--"one setting per file" makes this feature 
less than useless to me.  It becomes something where I will have to 
waste time defending against people using it.  I'd prefer to not have 
this at all than to do it that way.

That we're breaking these settings off into their own file, instead of 
trying to edit the postgresql.conf, to me is a pragmatic trade-off to 
keep the implementation from being really complicated.  It's also a step 
forward in a larger series for how to improve configuration management.  Just because that change introduces an entire
directorybeing scanned, 
 
I don't see that as an excuse to clutter it with a long list of files too.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Strange Windows problem, lock_timeout test request
Next
From: Guillaume Lelarge
Date:
Subject: Re: [COMMITTERS] pgsql: Move pqsignal() to libpgport.