Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 55156

Summary:	Postgres Upgrade problems
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <jgiglio>
Component:	postgresql	Assignee:	Trond Eivind Glomsrxd <teg>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	lowen, robertk
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-12-03 23:22:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Need Real Name 2001-10-26 14:10:34 UTC

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.

Comment 1 Need Real Name 2001-10-29 13:12:27 UTC

psql template1 also gives:
psql: relocation error: psql: undefined symbol: PQgetssl

Comment 2 Need Real Name 2001-10-29 13:29:08 UTC

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.

Comment 3 Trond Eivind Glomsrxd 2001-10-30 19:36:24 UTC

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.

Comment 4 David Kaplan 2001-12-03 23:00:48 UTC

This is the second time I have gotten burned on the same basic problem.

Comment 5 Lamar Owen 2001-12-03 23:22:30 UTC

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

Comment 6 Trond Eivind Glomsrxd 2002-02-11 17:04:26 UTC

The rh-pgdump script has been removed from  postgresql 7.2-2. You can try
pg_upgrade in postgresql-contrib.