From: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> |
---|---|
To: | Mike Mascari <mascarm(at)mascari(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Struggles with RC1 and RPMS |
Date: | 2000-04-18 15:47:25 |
Message-ID: | 38FC838D.AB25A1F3@wgcr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)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
From | Date | Subject | |
---|---|---|---|
Next Message | Frank Bax | 2000-04-18 16:18:50 | psql & java |
Previous Message | Nilesh A. Phadke | 2000-04-18 15:34:59 | Urgent ... Accessing the Index Structure |