Re: Redhat 7 and PgSQL - Mailing list pgsql-general
From | Lamar Owen |
---|---|
Subject | Re: Redhat 7 and PgSQL |
Date | |
Msg-id | 39D4D1F3.F8C4C519@wgcr.org Whole thread Raw |
In response to | Re: Redhat 7 and PgSQL (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-general |
Trond Eivind Glomsrød wrote: > Peter Eisentraut <peter_e@gmx.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
pgsql-general by date: