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

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date: 2013-03-17 16:05:55
Message-ID: 5145E9E3.7090200@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 toward the 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 directory being scanned,
I don't see that as an excuse to clutter it with a long list of files too.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-03-17 16:06:59 pgsql: Move pqsignal() to libpgport.
Previous Message Tom Lane 2013-03-17 15:07:12 Re: Strange Windows problem, lock_timeout test request