Re: Best OS for Postgres 8.2 - Mailing list pgsql-performance

From Robert Treat
Subject Re: Best OS for Postgres 8.2
Date
Msg-id 200705112312.57390.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Best OS for Postgres 8.2  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-performance
On Tuesday 08 May 2007 23:31, Greg Smith wrote:
> On Tue, 8 May 2007, Tom Lane wrote:
> > What Debian has done is set up an arrangement that lets you run two (or
> > more) different PG versions in parallel.  Since that's amazingly helpful
> > during a major-PG-version upgrade, most of the other packagers are
> > scheming how to do something similar.
>
> I alluded to that but it is worth going into more detail on for those not
> familiar with this whole topic.  I normally maintain multiple different PG
> versions in parallel already, mostly using environment variables to switch
> between them with some shell code.  Debian has taken an approach where
> commands like pg_ctl are wrapped in multi-version/cluster aware scripts,
> so you can do things like restarting multiple installations more easily
> than that.
>
> My issue wasn't with the idea, it was with the implementation.  When I
> have my newbie hat on, it adds a layer of complexity that isn't needed for
> simple installs.

I think I would disagree with this. The confusion comes from the fact that it
is different, not that it is more complex.  For new users what seems to be
most confusing is getting from install to initdb to logging in... if you tell
them to use pg_ctlcluster rather than pg_ctl, it isn't more confusing, there
just following directions at that point anyway.  If the upstream project were
to switch to debian's system, I think you'd end most of the confusion, make
it easier to run concurrent servers and simplify the upgrade process for
source installs, and give other package maintiners a way to achive what
debian has.  Maybe in PG 9...

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

pgsql-performance by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: BUG #3270: limit < 16 optimizer behaviour
Next
From: Tarhon-Onu Victor
Date:
Subject: 500 requests per second