Thanks for pointing me in the right direction. I started to look at the
db.out file and I noticed the pg_shadow variables. When I looked at the
newly built postgres 7.0.2 the usesysid for postgres was the same as the
usesysid for sys_request, one of the new accounts I was moving over. I
fixed all of the usesysid's in the db.out file to be a few digits away from
the postgres account. On top of that, however, I was also able to
successfully get rid of the real user accounts and add in generic accounts
that create and control each particular database. How happy is that? ;-)
Thanks again.
Oh, but one other question to the group...has anyone experienced any issues
when importing a database out of and older version and into a newer version?
We have several perl script which make modifications to the tables through
apache. Are there any commands or functions that completely disappear from
the old versions or is there usually some alias built in if a command is
replaced? We just need to make sure that we won't be losing any of the
functionality before upgrading on the production box.
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, July 24, 2000 4:04 PM
To: Fetter, David M
Cc: PostgreSQL-General (E-mail)
Subject: Re: [GENERAL] [General] Problems upgrading from v6.4.2 to
v7.0.2
"Fetter, David M" <Fetter.David@emeryworld.com> writes:
> Here's an example of what I'm talking about:
> List of Databases
> Database | Owner
> -------------------------
> inv | mgdotson
> inventory | rssouthw
> ir | mgdotson
> lpdb | lpadmin
> passwd | mgdotson
> sys_request | postgres <--wrong, doesn't exist in
> production db
> sys_request | sys_request <--correct
> template1 | postgres <--correct
> template1 | sys_request <--wrong, doesn't exist in production db
> tivoli | mgdotson
> For the record the exact commands I'm using to export and import this
> database are:
> pg_dumpall > db.out <--on 6.4.2 production postgres
> psql -d template1 -f db.out <--on 7.0.2 test postgres
Pretty bizarre. Have you looked at the dump file to see whether the
fault is wrong output from 6.4.2, or 7.0 doing the wrong thing?
My guess is that the pg_dumpall shell script is getting confused;
it's a pretty simplistic script (particularly as far back as 6.4)
and used to have a number of bugs for off-the-beaten-track cases.
I think it may still fall over if you have a space in a database
name, for example.
regards, tom lane