Re: Permanent settings

From: "Josh Berkus" <josh(at)agliodbs(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, Gregory Stark <stark(at)enterprisedb(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>
Subject: Re: Permanent settings
Date: 2008-02-20 23:02:49
Message-ID: web-15430532@davinci.ethosmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gevik Babakhani 2008-02-20 23:12:12 Re: Which MemoryContext?
Previous Message Tom Lane 2008-02-20 22:59:27 Re: Getting available options