Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]
От | Lamar Owen |
---|---|
Тема | Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0] |
Дата | |
Msg-id | 3784EE49.697C70FD@wgcr.org обсуждение исходный текст |
Ответ на | Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0] (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: