Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) - Mailing list pgsql-hackers

> Bruce Momjian wrote:
> > > At the risk of being redundant, here goes.  As I've explained before,
> > > the RPM upgrade environment, thanks to our standing with multiple
> > > distributions as being shipped as a part of the OS, could be run as part
>  
> > OK, maybe doing it in an RPM is the wrong way to go.  If an old version
> > exists, maybe the RPM is only supposed to install the software in a
> > saved location, and the users must execute a command after the RPM
> > install that starts the old postmaster, does the dump, puts the new
> > PostgreSQL server in place, and reloads the database.
> 
> That's more or less what's being done now.  The RPM's preinstall script
> (run before any files are overwritten from the new package) backs up the
> required executables from the old installation.  The RPM then overwrites
> the necessary files, and then any old files left over are removed, along
> with database removal of their records.
> 
> A script (actually, two scripts due to a bug in the first one) is
> provided to dump the database using the old executables.  Which works OK
> as long as the new OS release is executable compatible with the old
> release.  Oliver Elphick originally wrote the script for the Debian
> packages, and I adapted it to the RPM environment.
> 
> 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.

> > You are basically saying that because you can ship without a compiler
> > sometimes, we are supposed to change the way our regression tests work.
> > Let's suppose SCO says they don't ship with a compiler, and wants us to
> > change our code to accomodate it.  Should we?  You can be certain we
> > would not, and in the RPM case, you get the same answer.
>  
> > If the patch is trivial, we will work around OS limitations, but we do
> > not redesign code to work around OS limitations.  We expect the OS to
> > get the proper features.  That is what we do with NT.  Cygwin provides
> > the needed features.
> 
> No, I'm saying that someone running any OS might want to do this:
> 1.)    They have two machines, a development machine and a production
> machine.  Due to budget constraints, the dev machine is an el cheapo
> version of the production machine (for the sake of argument, let's say
> dev is a Sun Ultra 1 bare-bones workstation, and the production is a
> high end SMP Ultra server, both running the same version of Solaris).

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?

> > This is the "Hey, other people can do it, why can't you" issue.  We are
> > looking for suggestions from Linux users in how this can be done.
> > Perhaps running a separate command after the RPM has been installed is
> > the only way to go.
> 
> It's not really an RPM issue -- it's a PostgreSQL issue -- there have
> 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,
> Debian packages, and other binary packages just put the extant problem
> in starker contrast.  Until such occurs, I'll just have to continue
> doing what I'm doing -- which I consider a stop-gap, not a solution.

Yes, we all agree upgrades should be smoother.  The problem is that the
cost/benefit analysis always pushed us away from improving it.

> 
> 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.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026