Re: Permanent settings
От | Josh Berkus |
---|---|
Тема | Re: Permanent settings |
Дата | |
Msg-id | web-15430532@davinci.ethosmedia.com обсуждение исходный текст |
Ответ на | Re: Permanent settings (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Permanent settings
Re: Permanent settings Re: Permanent settings Re: Permanent settings |
Список | pgsql-hackers |
All, I think we're failing to discuss the primary use-case for this, which is one reason why the solutions aren't obvious. And that use case is: multi-server management. PostgreSQL is *easy* to manage on one server. For a single server, the existing text file editor GUIs are clunky but good enough. However, imagine you're adminning 250 PostgreSQL servers backing a social networking application. You decide the application needs a higher default sort_mem for all new connections, on all 250 servers.How, exactly, do you deploy that? Worse, imagine you're an ISP and you have 250 *differently configured* PostgreSQL servers on vhosts, and you need to roll out a change in logging destination to all machines while leaving other settings untouched. We need a server-based tool for the manipulating postgresql.conf, and one which is network-accessable, allows updating individual settings, and can be plugged into 3rd-party server management tools. This goes for pg_hba.conf as well, for the same reasons. If we want to move PostgreSQL into larger enterprises (and I certainly do) we need to make it more manageable. Now, none of this requires managing the settings via the SQL command line. Since we need to make it network-accessable, though, that seems the easiest route. Otherwise, we'd have to set up a daemon running on a 2nd port. P.S. I don't care what the syntax is. Josh Berkus PostgreSQL @ Sun San Francisco 415-752-2500
В списке pgsql-hackers по дате отправления: