Re: [GENERAL] Problems upgrading from v6.4.2 to v7.0.2
"Fetter, David M" <[EMAIL PROTECTED]> writes: > 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. Ah, that explains that. Another corner case that pg_dumpall doesn't handle :-(. I think we are planning to eliminate usesysids entirely soon, since they don't seem to have any real function other than creating the risk of this sort of problem... > 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 try to minimize cross-version portability problems, but there are always a few. The release notes for 7.0 should give you more info. regards, tom lane
RE: [GENERAL] Problems upgrading from v6.4.2 to v7.0.2
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
[GENERAL] [General] Problems upgrading from v6.4.2 to v7.0.2
I'm having some issues upgrading our production postgresql, which is at version 6.4.2, to version 7.0.2. Here's what is happening... I configure and make the new version of postgres (this is being done on a separate system from the production for testing purposes). On the production system I do a pg_dumpall to extract all of our current running databases. I then ftp the outfile to the test system and perform the import function as specific in the INSTALL file. After doing this I have a little dilemma right off the start. I have two databases that are duplicated but owned by separate users. One database is just a production one which is owned by postgres and the duplicate owned by the correct user as it lists on the production system. The other database that is duplicated is template1. This, I think, poses more of an issue. The first template1 db is owned by postgres and the second is owned by the correct owner for the other duplicated db. 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 Does anybody know why this is happening and more importantly how to get it not to happen? Also, I'm sure you may have noticed that some of the databases are owned by regular user accounts (i.e. mgdotson and rssouthw). How would I change the ownerships of these databases and tables to different generic users, given that the generic users are already created? I would like to do this with the upgrade process as well. Thank you, David M. Fetter UNIX System Analyst Emery World Wide "It has become appallingly clear that our technology has surpassed our humanity." - Albert Einstein Fetter, David M.vcf
