Bug 62013 - postgres 7.2 upgrade postgresql-dump gives errors and does not run
Summary: postgres 7.2 upgrade postgresql-dump gives errors and does not run
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: postgresql
Version: skipjack-beta1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks: 61590
TreeView+ depends on / blocked
 
Reported: 2002-03-26 18:27 UTC by Need Real Name
Modified: 2007-04-18 16:41 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-04-10 21:20:07 UTC
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2002-03-26 18:27:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314

Description of problem:
Following the recommended upgrade procedure for the postgres 7.2 install  failed
giving errors indicating the shell script has not been tested, and that binaries
are not in the expected location. 


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Install Red Hat 7.2
2.Build database in postgres 7.1.3
3.Upgrade to SkipJack
4.Follow instructions for postgers upgrade

	

Actual Results:  
bash-2.05a$  postgresql-dump  -t /var/lib/pgsql/backups/db.bak -p
/var/lib/pgsql/backups/old -d
/usr/bin/postgresql-dump: [: /var/lib/pgsql/backups/db.bak: unary operator expected
/usr/bin/postgresql-dump: [: /var/lib/pgsql/backups: unary operator expected
/usr/bin/postgresql-dump: [: /var/lib/pgsql: unary operator expected
/usr/bin/postgresql-dump: [: /var/lib: unary operator expected
/usr/bin/postgresql-dump: [: /var: unary operator expected
/usr/bin/postgresql-dump: /usr/lib/pgsql/backup/postmaster: No such file or
directory



Additional info:

the /usr/bin/postgresql-dump script has errors in it.
it expects things to be in : 
/usr/lib/pgsql/backup
They are actually in : 
/usr/share/pgsql/backup

PGLIB and BINDIR 
as well as bindir from /usr/share/pgsql/backup/pg_dumpall 
should be updated to refect the postgresql 7.1 binaries location.

Also when I changed things like : 
               if [ "${new_pm_pid}" = "${pm_pid}" ]
to : 
               if [ A${new_pm_pid} = A${pm_pid} ]
this caused the "shell errors" to go away. 

It appears that the "upgrade" scripts have not changed since Raw Hide 7.2-3. 

If these things are fixed then it will be easier to upgrade to postgres 7.2

Comment 1 Trond Eivind Glomsrxd 2002-03-27 18:07:09 UTC
Where did you find that upgrade procedure?

Comment 2 Need Real Name 2002-03-27 18:24:22 UTC
/usr/share/doc/postgresql-7.2/README.rpm-dist 

Section UPRADING describes the postgresql-dump procedure that I used. 

Is there another set of upgrade procedures I should have used? 










Comment 3 Trond Eivind Glomsrxd 2002-03-27 22:28:25 UTC
I've moved the directories back to where they should be... should probably add
to docs, and perhaps even remove this band aid: People need to dump first,
upgrade second.

Comment 4 Need Real Name 2002-03-28 19:15:16 UTC
Question. 
Is there a way to make the rpm -U process do a dump of the existing postgres 
databases?. Then as part of the post installation phase 
restore the dump if the previously installed version was 7.1.x? 

This would make the skipjack upgrade a little more seamless for those people 
who are running databases who are not DBA's. 

A DBA I would expect to know to do a full dump of all databases prior to an upgrade
a newbie/learner trying out things I would not expect to know this. 





Comment 5 Trond Eivind Glomsrxd 2002-04-10 17:59:27 UTC
We did that a long time ago. Problems:

* if something goes bad, you don't monitor it and aren't aware of the problem
other than the data being gone 
* space (yes, it's a part of the above, but too important not to be mentioned
separately)

Comment 6 Need Real Name 2002-04-10 21:20:00 UTC
So does this mean an advisory should go out with Skipjack final stating: 

All postgres 7.1 users should backup all database data prior to upgrade? 











Comment 7 Trond Eivind Glomsrxd 2002-04-10 23:55:36 UTC
This procedure is part of the releasenotes in old releases, they're part of it
this time too.

I've also removed the program, and made sure to mention that in the above RPM.
7.2.1-4


Note You need to log in before you can comment on or make changes to this bug.