Re: postgres upgrade for dummies?
On Sun, Feb 17, 2002 at 01:38:52 +0100, Andreas Goesele wrote: I now did a new try, again without any success. The automatic upgrading process first looks promising but than ends with the following error message: You are now connected to database template1 as user user. create database user; ERROR: parser: parse error at or near user user is a reserved word in 7.1. Either rename the database before upgrading to 7.1, or do the upgrade by hand and edit the database, putting double quote marks around the occurances of user as a database name. So I did read README.Debian.migration.gz and then run postgresql-dump with the options in the README. This is what I got: Stopping and restarting the postmaster /usr/lib/postgresql/dumpall/6.5/postmaster -D /var/lib/postgres/data -p 5431 -o -d0 Dumping the database to db.out process_hba_record: invalid syntax in pg_hba.conf file Switch back to the pg_hba.conf file you used with 6.5. 7.1 has a new authentication method peer which 6.5 doesn't understand and which 7.1's default configuration employs IIRC. HTH, Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
Re: postgres upgrade for dummies?
On Sun, 2002-02-17 at 14:20, J.H.M. Dassen (Ray) wrote: On Sun, Feb 17, 2002 at 01:38:52 +0100, Andreas Goesele wrote: So I did read README.Debian.migration.gz and then run postgresql-dump with the options in the README. This is what I got: Stopping and restarting the postmaster /usr/lib/postgresql/dumpall/6.5/postmaster -D /var/lib/postgres/data -p 5431 -o -d0 Dumping the database to db.out process_hba_record: invalid syntax in pg_hba.conf file Switch back to the pg_hba.conf file you used with 6.5. 7.1 has a new authentication method peer which 6.5 doesn't understand and which 7.1's default configuration employs IIRC. This particular issue will go away in 7.2. The peer authentication method (checking ownership of a Unix socket connection) has been adopted upstream but is now called ident, although its method of operation is actually different from TCP/IP ident authentication. So, in 7.2, peer will again be invalid. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Surely he took up our infirmities and carried our sorrows; yet we considered him stricken by God, smitten by him, and afflicted. But he was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed.Isaiah 53:4,5
Re: postgres upgrade for dummies?
J.H.M. Dassen (Ray) [EMAIL PROTECTED] writes: Switch back to the pg_hba.conf file you used with 6.5. 7.1 has a new authentication method peer which 6.5 doesn't understand and which 7.1's default configuration employs IIRC. This helped. Thanks. But now I have a new problem: The encoding of my database is latin1. During the upgrade with postgresql-dump -t db.out -dcivlp $PGDATA/../data.save the screen dump looked fine (all umlauts were correctly displayed). But now instead of the umlauts I have some strange combination of letters and signs. My name becomes for instance G(Hlaele. Listing the databases with \l shows the correct encoding LATIN1 and also the ordering as according to the German rules. Any solution to that? Thanks again! Andreas Goesele
Re: postgres upgrade for dummies? [solved]
Andreas Goesele [EMAIL PROTECTED] writes: J.H.M. Dassen (Ray) [EMAIL PROTECTED] writes: Switch back to the pg_hba.conf file you used with 6.5. 7.1 has a new authentication method peer which 6.5 doesn't understand and which 7.1's default configuration employs IIRC. This helped. Thanks. But now I have a new problem: The encoding of my database is latin1. During the upgrade with postgresql-dump -t db.out -dcivlp $PGDATA/../data.save the screen dump looked fine (all umlauts were correctly displayed). But now instead of the umlauts I have some strange combination of letters and signs. My name becomes for instance G(Hlaele. Listing the databases with \l shows the correct encoding LATIN1 and also the ordering as according to the German rules. The problem was the pager psql was using. Changing that to less solved the problem. (It remains strange anyway, that the problem appeared: more is working flawlessly on my system and the psql manpage claims that psql is using more as default pager.) Andreas Goesele
postgres upgrade for dummies?
Hi, Short story: Is there an easy way to upgrade from postgresql 6.5 to 7.1? An easy to follow document explaining how to do it? Long story: Many tries, no success: I have a nicely working postgresql 6.5 on Debian woody. When I first upgraded to woody I too tried to upgrade to postgresql 7.1, but I couldn't get my databases working. So with some work I went back to 6.5. I now did a new try, again without any success. The automatic upgrading process first looks promising but than ends with the following error message: You are now connected to database template1. select datdba into table tmp_pg_shadow from pg_database where datname = 'template1'; SELECT delete from pg_shadow where usesysid tmp_pg_shadow.datdba; DELETE 0 drop table tmp_pg_shadow; DROP copy pg_shadow from stdin; You are now connected to database template1 as user user. create database user; ERROR: parser: parse error at or near user \connect: FATAL 1: Database user does not exist in the system catalog. Reload failed Restarting PostgreSQL database: postmaster Stopped /usr/lib/postgresql/bin/postmaster (pid 28000). Starting PostgreSQL postmaster. postmaster successfully started . dpkg: Fehler beim Bearbeiten von postgresql (--configure): Unterprozess post-installation script gab den Fehlerwert 130 zurück Fehler traten auf beim Bearbeiten von: postgresql E: Sub-process /usr/bin/dpkg returned an error code (1) Afterwards it's impossible to start postmaster and connect to it. I turnt successfully back to 6.5 and tried it a second time: No I only got: Do you want me to move your old configuration to the new files? [Y/n] Restarting PostgreSQL database: postmaster No /usr/lib/postgresql/bin/postmaster found running; none killed. The database is in an older format that cannot be read by version 7.1 of PostgreSQL. Run postgresql-dump to dump the old database and to reload it in the new format. *** READ /usr/share/doc/postgresql/README.Debian.migration.gz FIRST! *** The version 7.1 postmaster cannot be started until this is done. . So I did read README.Debian.migration.gz and then run postgresql-dump with the options in the README. This is what I got: Stopping and restarting the postmaster /usr/lib/postgresql/dumpall/6.5/postmaster -D /var/lib/postgres/data -p 5431 -o -d0 Dumping the database to db.out process_hba_record: invalid syntax in pg_hba.conf file Missing or erroneous pg_hba.conf file, see postmaster log for details Connection to database 'template1' failed. Missing or erroneous pg_hba.conf file, see postmaster log for details process_hba_record: invalid syntax in pg_hba.conf file Missing or erroneous pg_hba.conf file, see postmaster log for details Connection to database 'template1' failed. Missing or erroneous pg_hba.conf file, see postmaster log for details process_hba_record: invalid syntax in pg_hba.conf file Missing or erroneous pg_hba.conf file, see postmaster log for details Connection to database 'template1' failed. Missing or erroneous pg_hba.conf file, see postmaster log for details Finding the default encoding process_hba_record: invalid syntax in pg_hba.conf file Missing or erroneous pg_hba.conf file, see postmaster log for details Connection to database 'template1' failed. Missing or erroneous pg_hba.conf file, see postmaster log for details Usage: pg_encoding encoding_name | encoding_number Killing the postmaster This is the ASCII output of the dump for you to check: -- postgresql-dump on Sun Feb 17 01:28:21 CET 2002 from version 6.5 \connect template1 select datdba into table tmp_pg_shadow from pg_database where datname = 'template1'; delete from pg_shadow where usesysid tmp_pg_shadow.datdba; drop table tmp_pg_shadow; copy pg_shadow from stdin; \. -- postgresql-dump completed on Sun Feb 17 01:28:22 CET 2002 On the basis of this dump, is it OK to delete the old database? [y/n] n (The last n is mine, as the dump didn't look promising at all ...) Any suggestions? Andreas Goesele
