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(at)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(at)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(at)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(at)ferrari postgres]$ cd
/usr/doc/postgresql-7.0RC1/postgres
[mascarm(at)ferrari postgres]$ fgrep "pg_ctl" *.htm
[mascarm(at)ferrari postgres]$

Not a good sign. Maybe I'll get lucky and pg_ctl is a script:

[root(at)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(at)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(at)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