Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thursday, August 29, 2013, Andres Freund wrote:
>
> To quote Robert two mails up:
>
> > Huh? The problem with adminpack is that it doesn't let you modify
> > individual configuration settings. All you can do is rewrite an
> > entire file.

That's clearly fixable.

> I guess somebody could write a specialized client that
> > just uses that infrastructure to rewrite postgresql.conf. For all I
> > know, someone has. Even if not, I don't think that you can use that
> > to prove that people don't care about this feature. If nobody cares,
> > why are there 400 emails on this topic?!

Having 400 emails about it means it's contentious. That's quite different
from having a large demand. It does speak to the author's persistence as
well, but that shouldn't be a surprise.

> Also, doing it the adminpack way lacks even the most basic validity
> checks. And that's not really changeable.

I don't see why..? Admin pack could certainly be modified to take a
parameter and do appropriate verification before locking an object and
rewriting the file. It's what we're being expected to do in core, after
all. Indeed, we can't even do validity checks on all the options, which is
the crux of what I'm concerned about.

> Presumably one major reason why we don't have other|good GUIs is that
> it's ridicuously hard to make them work to an interesting extent with
> the current infrastructure.

Yet no one has tried to improve admin pack?

> If they give out superuser access it has to be to people who can follow
> rules. After all they don't DROP DATABASE; DELETE FROM pg_class; alter
> passwords; use adminpack (changing postgresql.conf..); ... All of which
> they can do.
>

This completely misses, or perhaps just ignores, the point. Disallowing
super user access can be difficult because there's a lot of *normal* DBA
activities which can't be easily done without it (like changing table
ownership or similar). The "createrole" option definitely improved things
but we aren't there yet. It's certainly easy to simply not install the
adminpack. The other concerns above are strawmen because they attack a
malicious DBA. I'm not talking about malicious DBAs but rather a generally
knowledgable DBA who changed shared_buffers up too high and then leaves on
vacation, while the OPs guys need to do a database restart for whatever
reason and then discover it doesn't start.

I bring up these concerns because I have environments where I can see
exactly this happening and I have a hard time believing that I'm somehow
alone.

Thanks,

Stephen