On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
