To: David Jantzen <djantzen@ql2.com>
cc: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: Mixing DBLink versions 
In-reply-to: <78AE7A6D-1E37-4B74-BFEA-0E94BA9FA2C9@ql2.com> 
References: <78AE7A6D-1E37-4B74-BFEA-0E94BA9FA2C9@ql2.com>
Comments: In-reply-to David Jantzen <djantzen@ql2.com>
	message dated "Mon, 15 Mar 2010 14:29:51 -0700"
Date: Mon, 15 Mar 2010 21:01:33 -0400
Message-ID: <26934.1268701293@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

David Jantzen <djantzen@ql2.com> writes:
> Due to some historical idiosyncracies in our environment, we have a custom 8.3.7 database installation built from source.  We'd like to install dblink into this, however there are some problems with doing so:

> 1) the 8.3.7 database was built on a CentOS 4 build box that has since gone away
> 2) currently we have only 8.3.9 code built against CentOS 5
> 3) the GCC compiler on CentOS 4 was quite old
> 4) possible API changes in dblink between those versions

> My question, how risky would it be to copy the dblink.so and .sql files from the CentOS 5 compilation of Postgres 8.3.9 over to the CentOS 4 compilation of Postgres 8.3.7?  If runtime errors result, how severe would they be?  I.e., would they take down a postgres backend or possibly the postmaster daemon? 

I think you've got a fundamental problem that you'd better fix.  If you
are unable to rebuild the database from source then you are unable to
update --- and you are already three minor versions behind and missing
multiple security and crash-risk bug fixes.  You're living on borrowed
time, and NEED to reinstantiate your ability to build for that platform.
Or move to a newer one.

FWIW, you could probably get back a RHEL4 build environment pretty
cheaply by setting up a suitable "mock" chroot on a recent Fedora
version (installed on the same type of hardware).

As for your direct question: no, I wouldn't count on that to work.
RHEL4 and RHEL5 had different glibc versions didn't they?

			regards, tom lane