News

Welcome to End Point’s blog

Ongoing observations by End Point people

PostgreSQL 8.4 on RHEL 4: Teaching an old dog new tricks

So a client has been running a really old version of PostgreSQL in production for a while. We finally got the approval to upgrade them from 7.3 to the latest 8.4. Considering the age of the installation, it should come as little surprise that they had been running a similarly ancient OS: RHEL 4.

Like the installed PostgreSQL version, RHEL 4 is ancient -- 5 years old. I anticipated that in order to get us to a current version of PostgreSQL, we'd need to resort to a source build or rolling our own PostgreSQL RPMs. Neither approach was particularly appealing.

While the age/decrepitude of the current machine's OS came as little surprise, what did come as a surprise was that there were supported RPMs available for RHEL 4 in the community yum rpm repository, located at http://yum.pgrpms.org/8.4/redhat/rhel-4-i386/repoview/ (modulo your architecture of choice).

In order to get things installed, I followed the instructions for installing the specific yum repo. There were a few seconds where I was confused because the installation command was giving a "permission denied" error when attempting to install the 8.4 PGDG rpm as root. A little brainstorming and a lsattr later revealed that a previous administrator, apparently in the quest for über-security, had performed a chattr +i on the /etc/yum.repo.d directory.

Evil having been thwarted, in the interest of über-usability I did a quick chattr -i /etc/yum.repo.d and installed the PGDG rpm. Away we went. From that point, the install was completely straightforward; I had a PostgreSQL 8.4.4 system running in no time, and could finally get off that 7.3 behemoth. Now to talk my way into an OS upgrade...

Learn more about End Point's Postgres Support, Development, and Consulting.

4 comments:

Anonymous said...

RHEL 4 is ancient? The very first release of EL4 was in 2005 but unless you aren't keeping your support current, and if you aren't why are you using RHEL at all, Update 8 was released just about exactly one year ago (2009-05-18).

Also, 'we'd need to resort to a source build or rolling our own PostgreSQL RPMs. Neither approach was particularly appealing,' while possibly not very appealing it is pretty much braindead simple to do. You also shouldn't have any really special issues, if the RHEL4 installation has been kept up to date.

Jon Jensen said...

Yeah, I consider RHEL 4 to be ancient, even when kept up to date. The system libraries are all old and numerous modern software packages won't build against them. Have you tried rebuilding any current Fedora packages on even RHEL 5? Many dependencies can't be met without extra kludgy workarounds on RHEL 5, to say nothing of RHEL 4.

That's not to say RHEL 4 isn't a usable system, but given a choice I sure wouldn't choose it for a new installation as we were required to do here.

Gary Chambers said...

@Jon Jensen
"Yeah, I consider RHEL 4 to be ancient, even when kept up to date. The system libraries are all old and numerous modern software packages won't build against them. Have you tried rebuilding any current Fedora packages on even RHEL 5? Many dependencies can't be met without extra kludgy workarounds on RHEL 5, to say nothing of RHEL 4."

I'm not sure that your point is relevant in the context of a database server. The last thing I'm going to do on my production server is build anything that might be sensitive to those so-called updated libraries to which you refer.

Jon Jensen said...

I'm not talking about building directly on the server, but deploying needed packages.

For example, Git, Perl modules used in PL/Perl, rsyslog, modern rsync, modern OpenSSH, etc. -- all things we use on dedicated database servers.