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

From Greg Smith
Subject Re: Best OS for Postgres 8.2
Date
Msg-id Pine.GSO.4.64.0705082302170.29385@westnet.com
Whole thread Raw
In response to Re: Best OS for Postgres 8.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Best OS for Postgres 8.2  (Robert Treat <xzilla@users.sourceforge.net>)
Re: Best OS for Postgres 8.2  (Andrew McMillan <andrew@catalyst.net.nz>)
List pgsql-performance
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.  And when I have my developer hat on, I found that need
to conform to the requirements of that system on top of Debian's already
unique install locations and packaging issues just made it painful to
build and work with with customized versions of Postgres, compared to
distributions that use a relatively simple packaging scheme (like the RPM
based RedHat or SuSE).

I hope anyone else working this problem is thinking about issues like
this.  Debian's approach strikes me as being a good one for a seasoned
systems administrator or DBA, which is typical for them.  I'd hate to see
a change in this area make it more difficult for new users though, as
that's already perceived as a PG weakness.  I think you can build a layer
that adds the capability for the people who need it without complicating
things for people who don't.

> and if someday you want commercial support for your OS, a Centos->RHEL
> update will get you there easily.

For those that like to live dangerously, it's also worth mentioning that
it's possible to hack this conversion in either direction without actually
doing an OS re-install/upgrade just by playing with the packages that are
different between the two.  So someone who installs CentOS now could swap
to RHEL very quickly in a pinch if they have enough cojones to do the
required package substitutions.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

pgsql-performance by date:

Previous
From: david@lang.hm
Date:
Subject: Re: FW:
Next
From: Greg Smith
Date:
Subject: Re: Best OS for Postgres 8.2