Description of Problem: Upon upgrading from RH 7.1 to 7.2, on a computer with a postgres database, the upgrade process does not create the backups that README.rpm-dist mentions. README.rpm-dist has many contradictions as to how to do the upgrade process, and what procedure to follow. After forcing a downgrade to the RH7.1 versions of the postgres RPMs using -U --oldpackages, exporting the database with pg_dump, reupgrading, deleting the data directory, running initdb, and then attempting to run pg_restore, it tells me: bash-2.05$ pg_restore db.out Archiver: input file does not appear to be a valid archive This is partly a documentation problem, and it seems at least to involve two real bugs, one that the Red Hat upgrade installer does not cause the backups of the old pg binaries to be made like rpm -U does, and two, incompatible dump formats (apparently), between postgres 7.1.3 and 7.0.3-8. I have tried the rh-dumpall script with the following results: bash-2.05$ rh-pgdump.sh db2.out Can't open /usr/lib/pgsql/backup/pg_dumpall_new: No such file or directory. /usr/lib/pgsql/backup/postmaster does not find the database system. Expected to find it in the PGDATA directory "/var/lib/pgsql", but unable to open file "/var/lib/pgsql/global/pg_control": No such file or directory /usr/bin/rh-pgdump.sh: [: too many arguments /usr/bin/rh-pgdump.sh: [: too many arguments Dumping the database to db2.out /usr/bin/rh-pgdump.sh: /usr/lib/pgsql/backup/pg_dumpall_new: No such file or directory Killing the postmaster Version-Release number of selected component (if applicable): postgres 7.1.3 and 7.0.3-8. How Reproducible: Unknown, but likely. See above, default redhat 7.1 postgres RPMs then upgrade via 7.2 anaconda installer.
psql template1 also gives: psql: relocation error: psql: undefined symbol: PQgetssl
Ignore the previous additional comment, regarding psql -e. That part alone was not a bug but an error on my part. The earlier report still stands.
The upgrade procedure changed again... I'm thinking of just dropping attempts at workaround and just state (as it's already done in the release notes). :Backup your data before upgrade". As long as the postgresql developers don't care about upgrades, it's not easily fixable.
This is the second time I have gotten burned on the same basic problem.
I have, without success, complained many times to the core developers about this problem. There is very little interest in fixing the problem -- it will be a great deal of work that they feel is better spent on more interesting things. Further, they think it is an RPM bug that causes this, not their problem. To get this fixed properly, complain on the postgresql HACKERS list -- see http://developer.postgresql.org/mailsub.php to subscribe to the list. Maybe one day this will properly get fixed. And I second Trond's emotions -- however, I am going to take a much closer look at the PostgreSQL upgrade process in the RPM's for PostgreSQL 7.2, due out shortly. Now, above it is griped that the Red Hat Upgrade installer (anaconda) isn't making the backup executables -- this should be filed as a bug against anaconda, if anaconda isn't executing the %pre scriplet properly. :-(. If it isn't, then I'm ripping out the whole mess, as the backup of the old executables is critical to the process. Better yet, a Conflicts: dependency against all older versions might do the trick, FORCING a manual upgrade. :-] I'll have to investigate how to throw the upgrade out without aborting the installer. Trond, any suggestions? Oh, the burnage from an upgrade from RedHat 5.0 to RedHat 5.1 is one of the reasons I got into this in the first place. So, dmkaplan, I feel your pain. I wish I could ameliorate it. :-( As to the README.rpm-dist errors, please be more specific about the section(s) in question, and I'll edit accordingly. -- Lamar Owen RPM Maintainer PostgreSQL Global Development Group. 1 Peter 4:11
The rh-pgdump script has been removed from postgresql 7.2-2. You can try pg_upgrade in postgresql-contrib.