Re: Unsafe GUCs and ALTER SYSTEM WAS: Re: ALTER SYSTEM SET
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: Unsafe GUCs and ALTER SYSTEM WAS: Re: ALTER SYSTEM SET |
Дата | |
Msg-id | 51FFEF33.4040702@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: Unsafe GUCs and ALTER SYSTEM WAS: Re: ALTER SYSTEM SET (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On 08/05/2013 08:21 PM, Josh Berkus wrote: > On 08/05/2013 11:14 AM, Stefan Kaltenbrunner wrote: >> * in a few years from now people will just use superuser over the >> network for almost all stuff "because its easy and I can click around in >> $gui", having potential "unsafe" operations available over the network >> will in turn cause a lot of actual downtime (in a lot of cases the >> reason why people want remote management is because the don't have >> physical/shell access - so if they break stuff they cannot fix) > > See thread "Disabling ALTER SYSTEM SET". > >> * for classic IaaS/SaaS/DBaaS the ALTER SYSTEM seems to be mostly >> useless in the current form - because most of them will not or cannot >> hand out flat out superuser (like if you run a managed service you might >> want customers to be able to tweak some stuff but say not >> archive/pitr/replication stuff because the responsibility for backups is >> with the hosting company) > > 100% in agreement. If someone thought we were serving DBAAS with this, > they haven't paid attention to the patch. > > However, there are other places where ALTER SYSTEM SET will be valuable. > For example, for anyone who wants to implement an autotuning utility. > For example, I'm writing a network utility which checks bgwriter stats > and tries adjusting settings over the network to improve checkpoint > issues. Not having to SSH configuration files into place (and make sure > they're not overridden by other configuration files) would make writing > that script a *lot* easier. Same thing with automated performance testing. seems like an excessively narrow usecase to me - people doing that kind of specific testing can easily do automation over ssh, and those are very few vs. having to maintain a fairly complex piece of code in postgresql core. Nevertheless my main point is that people _WILL_ use this as a simple convinience tool not fully understanding all the complex implications, and in a few years from now running people with superuser by default (because people will create "cool little tools say to change stuff from my tray or using $IOS app" that have a little small comment "make sure to create the user "WITH SUPERUSER" and people will follow like lemmings. Stefan
В списке pgsql-hackers по дате отправления: