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
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: postgresql   
(Show other bugs)
Version: skipjack-beta1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
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:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-10 21:20:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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:

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

Additional info:

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

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

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
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

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.

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