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

Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Trond Eivind Glomsrød <teg(at)redhat(dot)com>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Date: 2000-11-02 19:22:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackerspgsql-ports
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

In response to


pgsql-ports by date

Next:From: Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=Date: 2000-11-02 19:31:20
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous:From: Bruce MomjianDate: 2000-11-02 18:50:37
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

pgsql-hackers by date

Next:From: Lamar OwenDate: 2000-11-02 19:25:36
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (MakefileREADME
Previous:From: Bruce MomjianDate: 2000-11-02 19:17:34
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README

pgsql-general by date

Next:From: Justin FosterDate: 2000-11-02 19:26:10
Subject: Re: Memory Leak
Previous:From: Joseph ShraibmanDate: 2000-11-02 19:14:16
Subject: Re: how good is PostgreSQL

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