From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Optimization levels when compiling PostgreSQL... |
Date: | 2002-09-10 16:30:43 |
Message-ID: | 20020910163043.GF26147@ninja1.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Don't doubt it at all, but that reminds me: I need to add a message
> > reminding the developer to re-initdb when installing this version.
>
> The catversion check isn't good enough for you?
Nope, it's good enough and then some. I've gotten in the habit of
just re-initdb'ing and figured that's what the rest of the world did:
didn't realize there was a way of testing the catalog versions. My
life seems to be spent inside the DB and not playing with it from the
CLI.
> It seems you are busily reinventing a bunch of decisions that have
> already been made, and in most cases have stood the test of time.
> Perhaps you should be less eager to make this Sean's Own Postgres
> Version, and more eager to be pushing out something that matches
> what everyone else is testing.
Ouch! I hope not. Testing gcc optimizations and adding a developers
port of PostgreSQL hopefully isn't for just myself.
PostgreSQL has a chunk of work that needs to happen when setting it up
or upgrading and I am trying to smooth out as much of that as possible
such that installing PostgreSQL gets to the point of having it
reasonably tuned for the OS its being installed on after installing
the port. Its not that install PostgreSQL is hard, far from, but
there's a reasonable checklist of things that needs to happen and that
requires a certain requisite knowledge of the database, tuning, and
the OS you're on: something, for better or worse, I assume most
users/DBA's don't have. In a typical install, I generally do some
variation of the following:
*) setenv CFLAGS '-g -O3'
*) make
*) pg_dumpall > ~/db_dump
*) ${LOCALBASE}/etc/rc.d/010.pgsql.sh stop
*) make deinstall
*) make install
*) mv $PGDATA $PGDATA.old
*) initdb
*) diff -c $PGDATA.old/data/postgresql.conf $PGDATA/data/postgresql.conf > $PGDATA/data/postgresql.conf.patch
*) cd $PGSQL/data; patch -p0 < postgresql.conf.patch
*) edit postgresql.conf
*) ${LOCALBASE}/etc/rc.d/010.pgsql.sh start
*) psql -f ~/db_dump
*) vacuumdb -a -f -z
*) tweak various sysctl's to increase fd's, etc.
*) hopefully don't have to recompile the kernel with more shmem, etc
On some hosts, I've even got a script that I run that does all of that
for me because it's the exact same procedure every time. :-/ Getting
as much of that done and taken care of as possible would probably be
appreciated and enjoyed by others. It's not fool-proof, don't get me
wrong, but there's certainly some of that that can be automated, and
with tunables I'd like to for usabilities sake.
::shrug:: Usability's a touchy subject though and none of this will be
on by default so as to not offend the power-users out there. -sc
--
Sean Chittenden
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2002-09-10 16:36:28 | Re: [JDBC] problem with new autocommit config parameter |
Previous Message | Tom Lane | 2002-09-10 15:57:34 | Re: Optimization levels when compiling PostgreSQL... |