Re: Upgrade to Red Hat Linux 9 broke PostgreSQL

Quoting Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>:

> On Tuesday 15 April 2003 14:47, Network Administrator wrote:
> > When you say "forces upgrades" what do you mean?
>
> PostgreSQL forces you to dump under the old version, then install the new
> version, initdb, and restore your data. Package-based upgrades have extreme
>
> difficulty with the 'dump with previous version' bit, unless the sysadmin/DBA
>
> has done them prior to the package upgrade. IOW, PostgreSQL forces a
> non-standard (as compared with other system services (and user programs, for
>
> that matter)) upgrade path -- virtually all other daemons are capable of
> reading the old configs and data files or there is some form of data
> migration tool packaged that does not require the old version to use.

Ahhhh, ok. I see what you're saying. I guess the way I look at that is that
you have the OS and then you have the stuff that runs on the OS. I would not
expect PostgreSQL to be "upgradeable" in the same way. Of course the fact that
you **can** do that is probably very attractive to some sysadmins. I guess, I'm
old school. Give me the source so I can compile for my system.

> When I upgraded to RH8.0 from 7.3 on my production DNS server, the migration
>
> from BIND 8 to BIND 9 was a smooth as silk, all the way down to the $ORIGIN
> directives, eliminating the @'s, dropping the redundant IN's, etc. In fact,
> I was not even aware of the differences until I needed to do some maintenance
>
> on a zone file. Nothing broke, either.
>

True, true I had that same experience actually but your already past the
application (named) part here and there for the "compiling" phase, no? That
named.conf file and associated zone file would be very much like reloading a
database from a dump. I think the only time I've every had a problem in that
regard is with feilds that were of a "time" type. I seem to remember emailing
the list years ago about that. I just ran a program I have against the dump
file to change the field type.

> On MySQL, due to the modular storage manager they use, you can migrate table
>
> by table to a newer or just a different storage manager. But the old data
> doesn't become unusable under the new version. Reconciling his with our
> system catalog setup is not going to be easy -- in fact, it will be very
> difficult.

Ok, I what you're saying here. I must have mis-read the original email 'cause I
thought this a PostgreSQL upgrade not a migration from MySQL- my apologies-
questions though, wouldn't you have to use a dump/restore to move between RDBMS?
That's the way I've always done things but if there's another way I guess
school is in session for me :)

> > Seems to me you should **always** be able to compile software.
>
> Sure. You can do this; it complicates the sysadmin's job, however, when your
>
> packaged version of PHP you want to install doesn't recognize that you really
>
> do have PostgreSQL of the required version installed.

This is where I've had the issues- simply not being able to compile source
because something is missing. In one of the environment I'm in, I was tasked
with getting Progress running on RedHat because Progress said they supported
RedHat- which already is an issue, because a disto should not be the support
point. It should be the kernel version and other libraries. In any event I
never got it to work on RedHat because at the time RedHat kernel was an insecure
one and the next build up did not have the Dell Raid drive available so I
played the typical very corporate game of "finger pointing" (Dell says RedHat
has the driver, RedHat says Dell doesa) for weeks until I finally just built the
thing on Slackware and compiled the driver for the proper kernel.

> Debian's apt package wrapper (dpkg is still at the core) is excellent for
> resolving dependencies; Connectiva ported apt to RPM. See www.freshrpms.net
>
> for apt-get for RPM for various Red Hat versions, including 9. I use it
> myself; particularly useful when you need a third-party app that has tons of
>
> dependencies (such as the ALSA drivers, mplayer, and xine). 'apt-get install
>
> xine' (once apt knows from where you want to pull the packages; already set
> up if you download freshrpms' version of apt-get for RPM) and all the
> dependencies are automatically resolved (and installed, after your
> confirmation).

Very nice- wish I would have known about that for this last Progress install. I
finally found the one .so I needed with rpm-finder (I think thats the site). I
used the rpm2tgz converter on Slackware to pull out the file and things worked
find. Thats my ignorance of the whole rpm thing as well as (IMHO) the Progress
NOT be a big Linux supporter.

> For a GUI to apt, get synaptic (once you have apt4rpm on your
>
> box, apt-get install synaptic), and you will be amazed.
>
> And the two line incantation:
>
> apt-get update
> apt-get upgrade
>
> keeps my system supplied with necessary security errata.
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>

Well this email is going my saved-messages. Thanks for the "class" Lamar.

--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com