Re: [HACKERS] Struggles with RC1 and RPMS - Mailing list pgsql-general
From | Lamar Owen |
---|---|
Subject | Re: [HACKERS] Struggles with RC1 and RPMS |
Date | |
Msg-id | 38FC838D.AB25A1F3@wgcr.org Whole thread Raw |
In response to | Struggles with RC1 and RPMS (Mike Mascari <mascarm@mascari.com>) |
List | pgsql-general |
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
pgsql-general by date: