On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost <sfrost@snowman.net> wrote:
> 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.
Yet you can't ignore the fact that many people on these threads want
some form of this.
>> 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?
No, but multiple people have tried to do ALTER SYSTEM .. SET. Peter
had a crack at this problem, I fooled around with it (though I don't
think I ever got as far as publishing), and there were various others
as well (Greg Smith?).
> 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.
/me looks at Stephen incredulously.
In the first place, modifying postgresql.conf and not immediately
restarting the server to test your changes is probably the single most
basic DBA error imaginable. I have a hard time viewing such a person
as generally knowledgeable. I hope the DBA in question doesn't have
access to the switches, because he's probably the sort of guy who
reassigns switch ports and doesn't type "wr m" afterwards.
In the second place, the same guy can do the same thing today. He
just has to use "vi". In fact, I think this is a pretty common
failure mode in poorly-controlled environments where too many people
have access to the configuration files. Now maybe you're going to
tell me that the ops guys can't modify the configuration file because
they only have SQL-level access, but then how are they managing to
restart the database? They need to be able to run pg_ctl *as the
postgres user* to do that, and if they have shell access to that
account, all bets are off.
Sure, you can construct a scenario where this matters. The ops guys
have "sudo postgres pg_ctl" access but adminpack isn't installed and
they have no other way to modify the configuration file. But that's
just bizarre. And if that's really the environment you have, then you
can install a loadable module that grabs ProcessUtility_hook and uses
it to forbid ALTER SYSTEM on that machine. Hell, we can ship such a
thing in contrib. Problem solved. But it's surely too obscure a
combination of circumstances to justify disabling this by default.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
