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:[EMAIL PROTECTED]] 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" <[EMAIL PROTECTED]> 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