Re: 7.1 Release Date

Trond Eivind Glomsrød wrote:
> For Red Hat 4.x, that would be true - we don't support the ancient
> libc5 anymore (OTOH, we didn't include Postgres95 at the time either).

There were RPM's at the time, though -- I ran 6.1.1 for nearly a year on
RedHat 4.1 until I upgraded to RH 5 (which shipped 6.2.1) after being
cracked. Good thing it was a reinstall from scratch -- those 6.1.1 RPMs
were _very_ different from what RedHat shipped in 5.0.

> > Note that ANY RPM-based distribution is going to have this same
> > problem.

> Not just RPM-based - any distribution who upgrades when the system is
> offline.

Like Debian. Of course, the RPM postgresql-dump script came from the
Debian packages -- so Oliver knows where I'm coming from. However,
Debian upgrading is more intelligent in many areas than RPM upgrading
is.

> > Yes, Tom, the RPM-based OS's upgrade procedures are brain-dead.

> No, it's not - it's just not making assumptions like "enough space is
> present to dump everything somewhere" (if you have a multiGB database,
> dumping it to upgrade sounds like a bad idea), "the database server is
> running, so I can just dump the data" etc.

'Brain-dead' meaning WRT upgrading RPMs...:
1.) I can't start a backend to dump data if the RPM is installing under
anaconda;
2.) I can't check to see if a backend is running (as an RPM pre or post
script can't use ps or cat /proc reliably (according to Jeff Johnson) if
that pre or post script is running under anaconda);
3.) I can't even check to see if the RPM is installing under anaconda!
(ie, to have a more interactive upgrade if the RPM -U is from the
command line, a check for the dump, or a confirmation from the user that
he/she knows what they're getting ready to do) -- in fact, I would
prefer to abort the upgrade of postgresql RPM's in anaconda as it
currently stands -- but that might easily abort the whole install!
4.) I'm not guaranteed of package upgrade order with split packages;
5.) I'm not even guaranteed to have basic system commands available,
unless I Prereq: them in the RPM (which is the fix for that);
6.) The installation chroot system is flakey (again, according to Jeff
Johnson) -- the least things you do, the better. My current backing up
of the old executables was really more than Jeff wanted to see. Maybe
this is fixed in Pinstripe.
7.) The requirements and script orders are not as well documented as one
might want.
8.) If I need to do complex operations to upgrade a package, it
shouldn't be a problem to do so in a pre install script -- but it is a
big problem. There _are_ other packages that require some _interesting_
steps to upgrade....

> > But, it can also be argued that our dump/restore upgrade procedure
> > is also brain-dead.

> This is basically "no upgrade path. But you can dump your old data
> before upgrading. And you can insert data in the new database".

Vegetable upgrades. You have really trimmed it to essentials --
PostgreSQL has no upgrade path in actuality. I seem to remember several
messages to this list in the past about problems with restoring data
dumped under older versions....

Upgrades should just be this simple:
Install new version.
Start new version's postmaster, which issues a 'pg_upgrade' in safest
mode.
If pg_upgrade fails for any reason, get DBA intervention, otherwise,
just start the postmaster already!

This could just as easily be:
Install new version.
Run pg_upgrade if required.
Start postmaster, and it just runs.

It SHOULD be that simple. It CAN be that simple. Effort HAS been
expended already on this issue -- there is a pg_upgrade script already
written that tries to do some of this, but without actually translating
the contents of the relation files. Maybe we should file this as a bug
against pg_upgrade :-).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11