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

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.

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

2.) For greater security, the production machine has been severely
crippled WRT development tools -- if a cracker gets in, don't give him
any ammunition. Good procedure to follow for publicly exposed database
servers, like those that sit behind websites. Requiring such a server
to have a development system installed is a misfeature, IMHO.

3.) After compiling and testing PostgreSQL on dev, the user transfers
the binaries only over to production. All is well, at first.

4.) But then the load on production goes up -- and PostgreSQL starts
spitting errors and FATAL's. The problem cannot be duplicated on the
dev machine -- looks like a Solaris SMP issue.

5.) The user decides to run regression on production in parallel mode to
help debug the problem -- but cannot figure out how to do so without
installing make and other development tools on it, when he specifically
did not want those tools on there for security. Serial regression,
which is easily started in a no-make mode, doesn't expose the problem.

All I'm saying is that regression should be _runnable_ in all modes
without needing anything but a shell and the PostgreSQL binary
installation.

This is the problem -- it is not OS-specific.

> > RPM's are expected to 'rpm -U' and you can simply _use_ the new version,
> > with little to no preparation. At least that is the theory. And it
> > works for most packages.

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

And, BTW, welcome back from the summit. I heard that there was a little
'excitement' there :-).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11