Skip site navigation (1) Skip section navigation (2)

Re: symbol mismatches on minor version upgrades

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: symbol mismatches on minor version upgrades
Date: 2011-08-30 19:31:38
Message-ID: 25348.1314732698@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> A while ago, I blogged about the following problem:
> (http://petereisentraut.blogspot.com/2011/07/undefined-symbol.html)

While not wishing to deny that this can be a problem, I think you're
overstating this aspect:

> Now if this had been, say, plpython, which is also developed closely
> together with the backend, but is probably shipped in a separate binary
> package and has extra dependencies, so it might reasonably not be
> upgraded at the same time, there would be additional problems.  We
> should figure out a way to advise packagers about putting in tight
> enough version dependencies when this happens.

This is not possible at least in the Red Hat world, because all the
subpackages have exact-version-and-release dependencies tying them
together.  That's distro policy not just my whim, and I'd expect other
server-grade distros to have similar policies.

You're right though that doing a "yum update" underneath a running
server could cause transient failures until the server was restarted
with the new postgres executable.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-08-30 20:05:52
Subject: Re: spinlocks on HP-UX
Previous:From: Jaime CasanovaDate: 2011-08-30 19:24:14
Subject: Re: Comparing two PostgreSQL databases -- order of pg_dump output

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group