Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) - Mailing list pgsql-hackers
From | Lamar Owen |
---|---|
Subject | Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) |
Date | |
Msg-id | 3A01BEEB.8EBDC28D@wgcr.org Whole thread Raw |
In response to | Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-hackers |
Bruce Momjian wrote: > > However, the dependency upon the new version of the OS being able to run > > the old executables could be a killer in the future if executable > > compatibility is removed -- after all, an upgrade might not be from the > > immediately prior version of the OS. > That is a tough one. I see your point. How would the RPM do this > anyway? It is running the same version of the OS right? Did they move > the data files from the old OS to the new OS and now they want to > upgrade? Hmm. Well, let's suppose the following: J. Random User has a database server that has been running smoothly for ages on RedHat 5.2, running PostgreSQL 6.3.2. He has had no reason to upgrade since -- while MVCC was a nice feature, he was really waiting for OUTER JOIN before upgrading, as his server is lightly loaded and won't benefit greatly from MVCC. Likewise, he's not upgraded from RedHat 5.2, because until RedHat got the 2.4 kernel into a distribution, he wasn't ready to upgrade, as he needs improved NFS performance, available in Linux kernel 2.4. And he wasn't about to go with a version of GCC that doesn't exist. So he skips the whole RedHat 6.x series -- he doesn't want to mess with kernel 2.2 in any form, thanks to its abyssmal NFS performance. So he waits on RedHat 7.2 to be released -- around October 2001 (if the typical RedHat schedule holds). At this point, PostgreSQL 7.2.1 is the standards bearer, with OUTER JOIN support that he craves, and robust WAL for excellent recoverability, amongst other Neat Features(TM). Now, by the time of RedHat 7.2, kernel 2.4 is up to .15 or so, with gcc 3.0 freshly (and officially) released, and glibc 2.2.5 finally fixing the problems that had plagued both pre-2.2 glibc's AND the earliest 2.2 glibc's -- but, the upshot is that glibc 2.0 compatibility is toast. Now, J Random slides in the new OS CD on a backup of his main server, and upgrades. RedHat 7.2's installer is very smart -- if no packages are left that use glibc 2.0, it doesn't install the compat-libs necessary for glibc 2.0 apps to run. The PostgreSQL RPMset's server subpackage preinstall script runs about two-thirds of the way through the upgrade, and backs up the old 6.3.2 executables necessary to pull a dump. The old 6.3.2 rpm database entries are removed, and, as far as the system is concerned, no dependency upon glibc 2.0 remains, so no compat-libs get installed. J Random checks out the new installation, and finds a conspicuous log message telling him to read /usr/share/doc/postgresql-7.2.1/README.rpm. He does so, and runs the (fixed by then) postgresql-dump script, which attempts to start an old backend and do a pg_dumpall -- but, horrors, the old postmaster can't start, glibc 2.0 is gone and glibc 2.2 blows core loaded under postmaster-6.3.2. ARGGHHH.... That's the scenario I have nightmares about. Really. > Yes, but if we added capabilities every time someone wanted something so > it worked better in their environment, this software would be a mess, > right? Yes, it would. I'll work on a patch, and we'll see what it looks like. > > been e-mails from users of other OS's -- even those that compile from > > source -- expressing a desire for a smoother upgrade cycle. The RPM's, > Yes, we all agree upgrades should be smoother. The problem is that the > cost/benefit analysis always pushed us away from improving it. I understand. I'm looking at some point in time in the future doing a 'postgresql-upgrade' RPM that would include pre-built postmasters and other binaries necessary to dump any previous version PostgreSQL (since about 6.2.1 or so -- 6.2.1 was the first RedHat official PostgreSQL RPM, although there were 6.1.1 RPM's before that, and there is still a postgres95-1.09 RPM out there), linked to the current libs for that RPM's OS release. It would be a large RPM (and the source RPM for it would be _huge_, containing entire tarballs for at least 6.2.1, 6.3.2, 6.4.2, 6.5.3, and 7.0.3). But, this may be the only way to make this work barring a real migration utility. > > And, BTW, welcome back from the summit. I heard that there was a little > > 'excitement' there :-). > Yes, it was very nice. I will post a summary to announce/general today. Good. And a welcome back to Tom as well, as he went too, IIRC. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
pgsql-hackers by date: