Обсуждение: Struggles with RC1 and RPMS
Hello, I struggled (just a little) to get the new RC1 RPMS installed and working. The first thing I did was to backup my existing database: pg_dump stocks > stocks Things went fine. I then uninstalled the existing RPMS using GnoRPM. I downloaded the following RPMS from postgresql.org: postgresql-7.0RC1-0.5.i386.rpm postgresql-tcl-7.0RC1-0.5.i386.rpm postgresql-devel-7.0RC1-0.5.i386.rpm postgresql-tk-7.0RC1-0.5.i386.rpm postgresql-server-7.0RC1-0.5.i386.rpm and installed them: rpm -i postgresql*.rpm After I installed them, I tried to start up the server: [root@ferrari init.d]# ./postgresql start Checking postgresql installation: looks good! Starting postgresql service: failed. Damn. I read the postgresql script to see that its checking for the existence of the a previous installation to determine whether or not to perform an initdb. GnoRPM didn't complain about "unable to delete directory <x>" but I realized that the existence of the previous structure was fooling the script, so I removed it: rm -rf /var/lib/pgsql I'm sure that most people would have performed an upgrade (rpm -Uvh), but, ironically enough, I prefer to uninstall and reinstall for safety's sake. Somehow, that should work :-(. Now I tried to start the server again: [root@ferrari init.d]# ./postgresql start Checking postgresql installation: looks good! Starting postgresql service: postmaster [2528] Great. I'll load up my database and get going. First, I'll become user postgres, create my 'mascarm' id, then as user mascarm, I'll create the database 'stocks' and then import the stocks.dat file. Somehow, pg_dump should be able to generate an appropriate dump file to not require the user to have to recreate both the PostgreSQL user and database before a restore: psql stocks < stocks.dat (Some time later...) Damn. I've got a lot of data in there and I know it will take PostgreSQL hours if I don't run it with fsync off: ^C Okay. I dropped the database and recreated it. Now to turn fsync() off. The /etc/rc.d/init.d/postgresql script has changed. Its now using pg_ctl instead of calling the postmaster directly. Fine. I'll just read the pg_ctl man page: [mascarm@ferrari mascarm]$ man pg_ctl No manual entry for pg_ctl No luck today, I guess. I'll use lynx and read the html documentation: [mascarm@ferrari postgres]$ cd /usr/doc/postgresql-7.0RC1/postgres [mascarm@ferrari postgres]$ fgrep "pg_ctl" *.htm [mascarm@ferrari postgres]$ Not a good sign. Maybe I'll get lucky and pg_ctl is a script: [root@ferrari data]# more /usr/bin/pg_ctl #! /bin/sh ... Okay. More script reading today...It appears pg_ctl uses the -o flag as the flag to send options to the "postmaster" on startup. Now using -o -F to send an option to the "postgres" process in the pre-pg_ctl days is confusing enough. Now I have to use the -o option to "pg_ctl" to send the -o option to the "postmaster" to send the -F option to each "postgres" backend. I found a "postmaster.opts.default" file in /var/lib/pgsql/data, but it's empty withought sample options. At least Oracle's "init<SID>.ora" files contains some sample comments. So I guess its safest to modify /etc/rc.d/init.d/postgresql to run pg_ctl as: su -l postgres -c "/usr/bin/pg_ctl -o '-o -F' -w -D $PGDATA -p /usr/bin/postmaster start >/dev/null 2>&1" Probability that a novice user will be able to run PostgreSQL with fsync() off: 0% Now I can import my database: psql stocks < stocks.dat ...Occassional CREATE statements... and "You are now connected as new user mascarm." statements. I don't care for the word "new" in this output. It almost implies a user mascarm has been created for you. But, of course, you couldn't have got this far without realizing your going to have to create it yourself. Finally. The data is loaded and I'm ready to start pgaccess: [mascarm@ferrari mascarm]$ pgaccess Error in startup script: couldn't read file "/usr/pgaccess/main.tcl": no such file or directory Damn. Another script I'm going to have to change: [mascarm@ferrari mascarm]$ rpm -qil postgresql-tk I see that main.tcl is actually in "/usr/lib/pgsql/pgaccess/lib/". Now, su back to root and edit "/usr/bin/pgaccess", changing: PGACCESS_HOME=/usr/pgaccess to PGACCESS_HOME=/usr/lib/pgsql/pgaccess Try to start up pgaccess. Nope. The postmaster isn't running with '-i'. Change "/etc/rc.d/init.d/postgresql" again so that pg_ctl hands the '-i' option to the postmaster. Finally, success. -------------------------------------------- Mike Mascari
Mike Mascari wrote: First of all, THANK YOU! Now, on to the list.... > rm -rf /var/lib/pgsql > I'm sure that most people would have performed an upgrade (rpm > -Uvh), but, ironically enough, I prefer to uninstall and > reinstall for safety's sake. Somehow, that should work :-(. Now I > tried to start the server again: Well, not exactly. There is a backup script done during an upgrade of the server package that won't be done in an uninstall/install case. This backup script pops a copy of the old version's executables in a safe place (/usr/lib/pgsql/backup, IIRC) before the install phase of the upgrade is performed, while the old version's executables (and libraries) are available. The RPM upgrade process: pre-install script, install new files, run post-install script, run preunistall script of old version, uninstall old version (only the files that are different from the new version that were not overwritten), then postuninstall script of old RPM. Which has just shown me a process bug in my preinstall script. :-( > Great. I'll load up my database and get going. First, I'll become > user postgres, create my 'mascarm' id, then as user mascarm, I'll > create the database 'stocks' and then import the stocks.dat file. > Somehow, pg_dump should be able to generate an appropriate dump > file to not require the user to have to recreate both the > PostgreSQL user and database before a restore: The pg_dumpall script does this. > Okay. I dropped the database and recreated it. Now to turn > fsync() off. The /etc/rc.d/init.d/postgresql script has changed. > Its now using pg_ctl instead of calling the postmaster directly. > Fine. I'll just read the pg_ctl man page: > [mascarm@ferrari mascarm]$ man pg_ctl > No manual entry for pg_ctl Waiting on that man page.... > empty withought sample options. At least Oracle's "init<SID>.ora" > files contains some sample comments. So I guess its safest to > modify /etc/rc.d/init.d/postgresql to run pg_ctl as: Yes, we need a postmaster.opts.sample in there to get started. > su -l postgres -c "/usr/bin/pg_ctl -o '-o -F' -w -D $PGDATA -p > /usr/bin/postmaster start >/dev/null 2>&1" > Probability that a novice user will be able to run PostgreSQL > with fsync() off: 0% Probability that a novice needs to run with fync off: 0%. However, this will be better documented in the -1 RPM after official 7.0 release. > I see that main.tcl is actually in > "/usr/lib/pgsql/pgaccess/lib/". Now, su back to root and edit > "/usr/bin/pgaccess", changing: > PGACCESS_HOME=/usr/pgaccess > PGACCESS_HOME=/usr/lib/pgsql/pgaccess Ooops. Forgot to patch that back in after Bruce changed it back. Thanks for noticing. > Try to start up pgaccess. Nope. The postmaster isn't running with > '-i'. Change "/etc/rc.d/init.d/postgresql" again so that pg_ctl > hands the '-i' option to the postmaster. Ooooh. I thought I had fixed that. No, what I had fixed was my need for -i in my application.... :-) Look for a -0.6 RPM sometime today that will hopefully have the non-documentation issues fixed. Finally, a useful bug report of the RPMS.... Thanks again, Mike. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> > No manual entry for pg_ctl > Waiting on that man page.... The man pages are done and available at a secret, hidden location ;) Try something like http://www.postgresql.org/user-lounge/7.0/docs/man.tar.gz - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
Thomas Lockhart wrote: > > > > No manual entry for pg_ctl > > Waiting on that man page.... > > The man pages are done and available at a secret, hidden location ;) To be accessed by my Captain Postgres Secret Decoder Ring (TM)? ;-) If these man pages are going into the 7.0 final (or an RC2, if we have one), I can wait to package them until then; although I will go ahead, download, and experiment. Of course, we still have three weeks... I may put together a 0.7 of RC1 in a few days if needed. Oh, Thomas, let me know how the RC1-0.6 RPM's act on Mandrake 7, if you can. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11