Re: Redhat 7 and PgSQL

Trond Eivind Glomsrød wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > But claiming that you can't upgrade is painting over what might rather be
> > a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file
> > like this:

> > %preupgrade
> > pg_dumpall >somewhere

> 1) You don't know that postgresql is running. It probably isn't.
> 2) You don't know that you have the diskspace to do that.

3.) If you are running inside the Red Hat OS installer (which the
PostgreSQL RPM's currently _do_), you can't start a postmaster. You
can't ask the user anything. You can't tell the user anything. And a
postmaster is guaranteed NOT to be running. Oh, and you can't test to
see if you are being upgraded inside the installer or from the command
line, thanks to some other restrictions due to the special chroot()
environment of the installer :-).

So, the current strategy is:
1.) If this is an upgrade, backup the old postgres, postmaster,
libpq.so, pg_dump, and psql, and copy to a known place with a new
pg_dumpall.
2.) Upgrade (which means install the new, then delete anything that was
old that didn't get overwritten by the new).
3.) If the user tries to start a postmaster using the supplied script,
check the data tree:
a.) if there is nothing, initdb it;
b.) if there is a compatible version's tree, start postmaster;
c.) if there is an incompatible version's tree, print an error and
punt.
4.) If a data upgrade is necessary, then:
a.) perform a dump of the old database using the executables saved
above, using a special script that set all sorts of oddball options to
get the old to run;
b.) make a binary copy of the old data, just in case;
c.) whop the old tree into oblivion;
d.) start the new postmaster using the supplied script (which does you
initdb with all the right options for Red Hat);
c.) restore your data.

Step 4 is manual, with the only assist being the performance of the
dump. This process does not work well. Oliver Elphick I know has
similar problems with the Debian package upgrading, although Debian
allows its packages to interact on upgrades. The script used in the
RPM's is a modified copy of Oliver's Debian script, although RH7
includes another script that shold be used for RH7, due to some changes
made in the PostgreSQL 7 RPMset that made the postgresql-dump script die
a horrible screaming death.

Now, the way RPM's upgrade is designed into the RPM package system --
and the MySQL RPM's don't have these problems with the system. RPM is
designed to do unattended mass upgrading -- and it is the responsibility
of both the sysadmin doing the upgrade and the packager to make sure no
one gets hosed in the process. The semi-automatic method used is a
compromise, for sure -- but, it is better than alternatives.

Now, there are some problems with pg_dump, at least on one datamodel I
know of. We on that team are working up a detailed bug report for your
viewing pleasure for posting at a later date.

And MANY THANKS AND KUDOS to Philip Warner for adopting pg_dump and
kin!!! Hopefully the new pg_dump will clear some things up. Being able
to deal with large objects for the first time will be a lifesaver for
many.

Opinion seems to be pretty evenly split right now about seamless
upgrading -- of course, this is one program that absolutely MUST be
right.

Alot of people will be made very happy when this problem is solved.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11