Re: [HACKERS] Struggles with RC1 and RPMS

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

In response to

Responses

Browse pgsql-general by date

  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