Re: [HACKERS] symbol mismatches on minor version upgrades
On tis, 2011-08-30 at 15:31 -0400, Tom Lane wrote: 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. Well, the Debian packages don't do this. Obviously, they could, but no one has ever clarified this. Exactly which distribution policy is this? I would rather think that this is something that upstream needs to determine. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] symbol mismatches on minor version upgrades
Peter Eisentraut pete...@gmx.net writes: On tis, 2011-08-30 at 15:31 -0400, Tom Lane wrote: 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. Well, the Debian packages don't do this. Obviously, they could, but no one has ever clarified this. Exactly which distribution policy is this? https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package The discussion there doesn't go into all that much detail, but there have been enough bad experiences at Red Hat with partially-updated packages that people have very negative views of doing otherwise. I would rather think that this is something that upstream needs to determine. Since the upstream is shipping a single tarball, it's unlikely that they'll think about it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] symbol mismatches on minor version upgrades
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
Re: [HACKERS] symbol mismatches on minor version upgrades
Peter Eisentraut pete...@gmx.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
