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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
