Tom Lane wrote:
> There are several other bugfixes over 6.5 in the RPM already, so I
> see no good reason not to just remove those four symlinks; it certainly
> seems cleaner than kluging the RPM script...
> regards, tom lane
Yes, that's quite true.
Speaking of the rpms, I have just found a few issues that my other
testing had not found. Specifically:
* The data necessary to initdb is in postgresql-devel, not
postgresql-server (the files in /usr/lib/pgsql, specifically the bki
sources);
* There are no static libraries in postgresql-devel (libpq.a, et al --
these are normally located in /usr/lib)
* IMHO, a warning should be printed about proper updgrade procedure --
rpm -U just simply won't work as the rpms (and postgresql) are currently
implemented -- and, unfortunately, the rpm -Uvh style is the default
method for most users, as well as RedHat version updates, from 5.2 to
6.0, for example.
As far as enhancements go, the postgresql-server rpm could (not
necessarily should) check to see if a database structure exists in
/var/lib/pgsql (if so, move it out of the way), and perform an initdb.
Where this comes into play is when upgrading postgresql versions using
rpm -- the rpm uninstall does not blow away the whole PGDATA/base tree
-- in fact, it leaves _everything_ there. So, to upgrade, you must
either rm -rf the tree or mv it out of the way -- preferably before
doing an initdb.
What IS the right way to do this in an automated fashion? Currently, to
upgrade via rpm (on a box running SysV init, such as RedHat), you must
do the following:
1.) as postgres, pg_dumpall
2.) as postgres, backup pg_hba.conf
3.) as root, rpm -e all-old-postgresql-rpms (found using rpm -qa|grep
postgres) (automateable -- rpm -qa|grep postgresql|xargs rpm -e (check
that xargs syntax...))
4.) as root, blow away the /var/lib/pgsql tree, taking care not to blow
away your backup
5.) as root, rpm -i select-new-postgresql-rpms
6.) as postgres, initdb --pglib=/usr/lib/pgsql --pgdata=/var/lib/pgsql
7.) as root, Edit /etc/rc.d/init.d/postgresql as needed (to add -i, FE)
(to automate this, simply include -i by default, or give user a choice,
and sed away...)
8.) as root, start postmaster (/etc/rc.d/init.d/postgresql start)
9.) as postgres, psql -e template1 < pg_dumpall-backup-from-step-1
10.) as postgres, restore pg_hba.conf
11.) Restart production tasks, after testing.
Have I left anything out? Is it even desireable to automate this? (In my
case, I'm going to build a script to keep around to do this...)
Lamar Owen
WGCR Internet Radio