A while ago, I blogged about the following problem:
(http://petereisentraut.blogspot.com/2011/07/undefined-symbol.html)
Between PG 8.4.4 and 8.4.5, a new symbol PinPortal was added to the
backend and plpgsql was changed to call it. So in that particular case,
upgrading plpgsql without also upgrading the backend at the same time
would cause plpgsql to fail.
I thought this might have been an accident, but it happened again with
the upgrade from 8.4.7 to 8.4.8 (do_convert_tuple). So now I'm thinking
we ought to do something about this.
Obviously, we don't want to prevent bug fixes introducing new functions,
when necessary. But perhaps we should advise users about this or make
sure they don't install mismatching versions. Note that we have a
system in place to prevent calling mismatching major versions, but we
don't track mismatching minor versions.
There are a number of levels where this might be a problem:
As it happens, plpgsql and the backend are shipped in the same binary
package, so upgrading them together is really not a problem, you just
need to arrange to restart the server right away. This can be avoided
by loading the library using shared_preload_libraries. Perhaps that
should be promoted more for libraries like plpgsql that are closely
tied to the backend?
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.
In the future, we are presumably hoping for more people to write and
package extensions. So if someone writes some module and thinks, oh,
I'll use this do_convert_tuple() function, then their binary won't work
with older versions of 8.4.
How could we address these issues?
