Postgres のインストール
新規インストールあるいは以前のPostgresをアップグレードする場合のインストール方法:
最新の情報およびプラットフォームに依存する情報を確認してください。 Ultrix4.x、Linux、BSD/OS、NeXTに関するプラットフォーム依存の情報はこのファイルの最後に有ります。 /usr/src/pgsql/doc には、FAQ-Irix や FAQ-Linux などのファイルが有ります。 ftp://ftp.postgresql.org/pubにある INSTALL というファイルに、インストールに関する最新の情報が記載されています。
"テスト済み"プラットホームとしてリストに載っているのは、 以前のある時点においてソースコードを修正しないで Postgres をコンパイルし稼動した 実績があるという事です。 現在の開発グループは、これらすべてのプラットフォームを持って いないので、現在のリリースでは少しの問題の為にいくつかの プラットフォームで上手くコンパイルできない、あるいは Regression テストをパスしないことがあります。 このような周知の問題とそれらの解決方法は ftp://ftp.postgresql.org/pub/INSTALL にアップロードされます。
Postgresの為のスーパユーザアカウントが 無い場合、それを作成します。 通常、postgres という名前が使われています。
特権ユーザのアカウントでなければ,Postgresのファイルオーナーは任意に設定できます。 root や bin 、あるいは他の特別なアクセス権限を持つアカウントをオーナーにしてはいけません。 これがセキュリティ上の危険を発生させるかも知れないからです。
Postgresのスーパユーザアカウントでログインします。 これ以降に記載されている手順の大部分も、このアカウントで実行します。
ftp://ftp.postgresql.org/pub/postgresql-v6.5.3.tar.gz というファイルをインターネットからホームディレクトリに FTP 転送してください。
幾つかのプラットフォームでは、flex が使われています。 flex を使用している場合、バージョンを以下のように確認してください。
$ flex --version
flexというコマンドが無い場合、多分それは必要ありません。 もし、バージョンが 2.5.2 あるいは 2.5.4 の場合は問題無いのですが、2.5.3 あるいは 2.5.2 より以前の物の場合、アップグレードの必要があります。 ftp://prep.ai.mit.edu/pub/gnu/flex-2.5.4.tar.gz から入手してください。
flex が必要なのにインストールされていない無い場合、あるいは違ったバージョンがインストールされている場合、Postgresのコンパイル実行中にその旨が告げられます。 必要かどうかわからないときは、インストールしなくてかまいません。 Postgres をコンパイルしようとする時に、flexのインストールまたはアップグレードが必要なことがわかります。
flex をインストールする過程の全てで root権限 である必要はありません。 デフォルトの場所にインストールしたいのであれば、以下のようにしてください:
$ su - $ cd /usr/local/src ftp prep.ai.mit.edu ftp> cd /pub/gnu/ ftp> binary ftp> get flex-2.5.4.tar.gz ftp> quit $ gunzip -c flex-2.5.4.tar.gz | tar xvf - $ cd flex-2.5.4 $ configure --prefix=/usr $ gmake $ gmake check # これ以降、root権限が必要です: $ gmake install $ cd /usr/local/src $ rm -rf flex-2.5.4
上記の手順では /usr/man/man1/flex.1、 /usr/bin/flex、 /usr/lib/libfl.a、 /usr/include/FlexLexer.hといったファイルを インストールし、/usr/bin/flex++ を flex に リンクします。
既存のシステムからアップグレードする場合以外は、step 9 までの作業を省略できます。 6.5からのバージョンアップの場合、データのダンプやリロード、あるいは initdb の実行は必要ありません。ソースをコンパイルし、 postmasterを止めてから "make install"を実行後、再度 postmaster を起動するだけです。 6.4.x やそれ以前からのアップグレードの場合、データベースのバックアップが必要になります。 アルファあるいはベータバージョンを使用されている場合、頻繁にデータベース形式が変更されることがあります。その時も簡単なコメントが開発者同士のメーリングリストに流される以外の情報もありませんので注意が必要です。 正式リリースでは常に旧バージョンのデータをダンプしたりリロードする作業が必要になりますのでこの章を読み飛ばさないでください。
Tip: v6.0のpg_dumpallは使わないようにしてください。 さもないと(ダンプされたデータベースの)あらゆる物のオーナーが Postgresのスーパユーザに設定されてしまいます。
今ある v6.0 以降の pg_dumpall を使用する場合、以下のようにします
$ pg_dumpall > db.out
Postgres をアップグレードする前に、今までのデータベースに対し最新版の pg_dumpall スクリプトを使用するには、以下のようにします:
$ cd $ gunzip -c postgresql-v6.5.1.tar.gz \ | tar xvf - src/bin/pg_dump/pg_dumpall $ chmod a+x src/bin/pg_dump/pg_dumpall $ src/bin/pg_dump/pg_dumpall > db.out $ rm -rf src
オブジェクトID(oids)をそのまま保存したい場合、pg_dumpall 実行時に -o オプションを使用してください。 しかしながら、OIDをキーに設定している等の特別な場合を除いてはこのオプションを使用しないで下さい。
pg_dumpall コマンドに非常に時間が掛かる場合、プロセスが死んでいるかもしれません。その場合、他のターミナルから以下のコマンドを実行してみてください。
$ ls -l db.out数回これを実行し、ファイルサイズが増加している事でプロセスが死んでいないか確認してください。
Postgres95 v1.09 以前からのアップグレードを行う場合、データベースのバックアップを必ず行い、Postgres95 v1.09のインストールを行ってから、データベースを v1.09 でリストアしてください。その後、バックアップを再度行います。 インストールの際、リリースノートに含まれるバージョン毎の特記事項を確認して下さい。
Caution |
バックアップの途中でデータベースの内容が更新されないようにしてください。 必要なら、postmaster を一旦停止し、 /usr/local/pgsql/data/pg_hba.conf を編集してあなただけがそれにアクセス出来るようにしてからバックアップを行って下さい。 |
バックアップが終了したら、postmaster を終了させます。 まず、以下のように入力します。
$ ps -ax | grep postmasterこれは実行中の postmaster のプロセス番号を表示します。 次の pid の個所を postmaster のプロセス番号に変えて入力し、プロセスを停止してください。 (grepコマンド自身のプロセス番号を使ってはいけません。)
$ kill pid
Tip: Postgresがシステム起動時に自動的にスタートするようになっている場合、PostgreSQL起動用スクリプトでプロセスを終了することができます。例えば、筆者のLinuxでは以下の様に入力してPostgresを終了させる事ができます。
$ /etc/rc.d/init.d/postgres.init stop
もし PostreSQLをアップグレードしている場合、古いPostgreSQLのディレクトリの名前を変えて保存しておきます。 ディスク容量が不足している場合、バックアップが終了した後に古いディレクトリを消さなければいけないかも知れませんが、その場合でも、/usr/local/pgsql/data にある古いデータベースを保存しておいてください。最低でも、/usr/local/pgsql/data/pg_hba.conf だけは、保存しておきます。
古いバージョンのPostgresを全て保存しておく場合、以下のように名前を変更します:
$ su - $ cd /usr/src $ mv pgsql pgsql_6_0 $ cd /usr/local $ mv pgsql pgsql_6_0 $ exit
もし/usr/local/pgsql/dataというディレクトリをデータベース保存用に使用していない場合、環境変数 PGDATA を参照しそのディレクトリを上記手順と同じ方法で保存しておきます。
新しいバージョンのソースファイルとプログラムのインストール用にディレクトリを作成します。インストール先のディレクトリ名は変更することが出来ますが、インストールの間は終始同じパスを使用しなければいけません。
Note: このマニュアルに書かれているインストール手順を使う場合、プログラムやライブラリ、ドキュメント等のインストール先の場所を指定するチャンスは2回程ありますが、通常は gmake install を実行する時に指定します。
ソースファイルとプログラムの為のディレクトリを作ります。
$ su $ cd /usr/src $ mkdir pgsql $ chown postgres:postgres pgsql $ cd /usr/local $ mkdir pgsql $ chown postgres:postgres pgsql $ exit
新しいソースファイルを以下のように展開します。
$ cd /usr/src/pgsql $ gunzip -c ~/postgresql-v6.5.1.tar.gz | tar xvf -
configureスクリプトを実行しますが、この時、--prefix オプション(詳しくは後述します)でプログラム等をインストールするディレクトリのパスを設定することが出来ます。
$ cd /usr/src/pgsql/src $ ./configure [ options ]
configure スクリプトはそのシステムに合ったテンプレートファイル を自動的にテンプレートディレクトリの中から選択しますが、それが 出来ない場合は、その旨を表示しスクリプトは停止します。 この場合、テンプレートから自分のシステムに合ったものを探し出し、 configure 実行時に--with-template=TEMPLATE オプションを指定しなければなりません。
問題の報告: もし configure が自動的にシステムを認識できなかった場合、 ./config.guess プログラムの出力を添付して scrappy@hub.orgまで メールしてください。また、どんなテンプレートファイルが使用される べきであったかも知らせてください。
configure時のオプション選択する場合、構成オプションで詳細を確認してください。しかし、マルチバイト文字のサポートや、 ロケール照合サポートなどのオプション機能無しの淡白なインストール をするのなら、インストールする場所を選んだ以外、特にオプションは指定 せずにconfigureを実行すれば十分でしょう。 configure スクリプトには、デフォルトの設定を変更するための多くのオプションが在ります。全てのオプションを見るには、以下のように入力します。
./configure --help通常使用されるオプションは以下のような物です:
--prefix=BASEDIR Postgresをインストールする
ディレクトリを指定します。
デフォルトでは /usr/local/pgsql にインストールされます。
--with-template=TEMPLATE
テンプレートファイルとして'TEMPLATE'を使います。
テンプレートファイルはsrc/template内にあります。
正しいテンプレート名は、このディレクトリの内容
を参照してください。
--with-tcl
libpgtclやpgtclsh、pgtksh等の Tcl/Tk を必要とする
ライブラリ及びプログラムをインストールします。
--with-perl Perl 用インターフェイスライブラリをインストールします。
--with-odbc ODBC ドライバ群をインストールします。
--enable-hba 'ホストベース認証'を有効にします
(デフォルトは、指定しなくても有効になっています。)
--disable-hba 'ホストベース認証'を無効にします。
--enable-locale USE_LOCALE を有効にします。
--enable-cassert ASSERT_CHECKING を有効にします。
--with-CC=compiler
configureスクリプトが C コンパイラを見つけることが
出来ない場合に C コンパイラを指定します。
--with-CXX=compiler
configureスクリプトが C++ コンパイラを見つけることが
出来ない場合に C++ コンパイラを指定します。
--without-CXX
C++コンパイラを使いません。
(上記2つのオプションは、libpg++にだけ関係します。)
以下の例は、Sparc Solaris 2.5 上でインストール先のディレクトリを /opt/postgres に指定しています:
$ ./configure --prefix=/opt/postgres \ --with-template=sparc_solaris-gcc --with-pgport=5432 \ --enable-hba --disable-locale
Tip: もちろん上記のコマンド全てを1行に入力する事も出来ます。
man ページや、HTML 形式の文書をインストールするには、以下のように入力します:
$ cd /usr/src/pgsql/doc $ gmake install
Postscript形式の文書も同じディレクトリ内に .ps.gz という拡張子付きでインストールされます。
次のようにして、コンパイルを行います。
$ cd /usr/src/pgsql/src $ gmake all >& make.log & $ tail -f make.log
コンパイルが正常に終了すると、最後は以下のように表示されます。
All of PostgreSQL is successfully made. Ready to install.再度言っておきますが、"gmake" が "make" とされているシステムも有ります。 この時、あるいはもっと早い段階で、コントロールキーとCを同じに押して tail コマンドを停止してもかまいません。しかし、make.log に記録されたエラーメッセージやワーニングメッセージで問題を調査することが出来ます。
Note: make.log に幾つかのワーニングメッセージが有るかもしれませんが、使用中に問題が発生しない場合は無視してかまいません。
もし、flex コマンドが見つからないというエラーメッセージと共にコンパイルが失敗した場合、前述したように flex をインストールして下さい。 その後、src ディレクトリに戻って次のコマンドを実行してからコンパイルを再実行します。
$ gmake clean
オプチマイザやデバッグ等のコンパイラオプションは、以下の例のように COPT 変数として入力することが出来ます。
$ gmake COPT="-g" all >& make.log &これは、コンパイル作業中の全ての状況で -g オプションをコンパイラが使うように指定しています。詳細は src/Makefile.global.in を参照してください。
インストールを実行します。
$ cd /usr/src/pgsql/src $ gmake install >& make.install.log & $ tail -f make.install.log
インストールが終了すると、以下のように表示されます。
gmake[1]: Leaving directory `/usr/src/pgsql/src/man'この時、あるいはもっと早い段階で、コントロールキーとCを同じに押して tail コマンドを停止してもかまいません。しかし、make.log に記録されたエラーメッセージやワーニングメッセージで問題を調査することが出来ます。 何度も言いますが、"gmake" が "make" とされているシステムも有ります。
共有ライブラリの場所をシステムがどのように見るけるかを指定しなければいけないことがあります。 以下の方法の中から、一つ 実行して下さい。 できれば最初の方法を使ってください:
root権限で、/etc/ld.so.conf ファイルに次の1行を追加します。
/usr/local/pgsql/libその後、/sbin/ldconfig コマンドを実行します。
bash を使用している場合、以下を入力します。
export LD_LIBRARY_PATH=/usr/local/pgsql/lib
csh の場合は、以下を入力します。
setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
OSの種類によって上記コマンドには大きな違いが見られます。 Ultrix4.x や ELF非対応のLinux などは、プラットフォーム依存の注意点を確認してください。
データベース作成時、以下のようなメッセージが表示されたら共有ライブラリの設定が必要です。
pg_id: can't load library 'libpq.so'前述の内容を実行してください。
configure 実行時、--with-perl オプションを使った時はインストールログを確認して Perl モジュールが正しくインストールされたか確認してください。 もし今までのインストール手順を忠実に守っていた場合、Perl ライブラリのディレクトリへの書き込み権限が無いことから、Perl モジュールのインストールはできていないはずです。 Perl モジュールのインストールは、 su コマンドで Perl ライブラリの持ち主(通常は root アカウント)になれれば、いつでも出来ます。
$ cd /usr/src/pgsql/src/interfaces/perl5 $ gmake install
まだ準備していなければ、Postgres を使用する postgresというアカウントを作成してください. 同様に、Postgres を使用する予定のその他の アカウントも準備しなければなりません.
Postgresの実行環境に影響を与える個別の事項 (実行環境を左右させる個別の方法)があります これに付いては Administrator's Guide に詳しい 説明があります。
Note: 以下の説明は、bash/sh シェルの為の物ですので、使用しているシェルの種類に応じて内容を変更してください。
以下の行を ~/.bash_profile 等のログイン環境変数に追加します:
PATH=$PATH:/usr/local/pgsql/bin MANPATH=$MANPATH:/usr/local/pgsql/man PGLIB=/usr/local/pgsql/lib PGDATA=/usr/local/pgsql/data export PATH MANPATH PGLIB PGDATA
regression テストでの幾つかのエラーは、標準の C ロケールとインストール環境でのロケール照合ロジックのデザインの違い により発生することがあります。
Postgres の configure あるいはコンパイル 実行時に--enable-locale オプションを指定した場合、 postmaster を起動する前に,ログイン時の 環境設定を追加し,ロケール環境を "C" にする(あるいは,すべての "LC_*" 変数の設定を消しておく) べきです。
LC_COLLATE=C LC_CTYPE=C export LC_COLLATE LC_CTYPE
次のステップを実行する前に、今までに行った環境変数の変更が正しく定義されたか確認しておいてください。環境変数を再定義する一番簡単な方法は、以下のように入力することです:
$ source ~/.bash_profile
Postgres のスーパユーザアカウントで、データベースを作成しますが、 ここでは、今まで通り postgres というアカウントを使用します。 重大なセキュリティホールになるので、以下の手順は、絶対に root アカウントでは実行しないで下さい!
$ initdb
/usr/local/pgsql/data/pg_hba.conf を編集することにより、データベースシステムへのアクセス権限を設定します。なお、詳細な説明は、ファイルの中にコメントとして記述されています。 (もし、デフォルト以外の場所にデータベースが有る場合、例えば PGDATA が他の場所を指定してある時等は、それに応じてこのファイルの場所は変わります。) このファイルは編集終了後、書き込み禁止に戻してください。 v6.0以降からのアップグレードの場合は,一からファイルを書かなくとも, 古い pg_hba.conf の内容を新しい同ファイルの先頭に コピーしてすませることができます.
コマンドラインからバックエンドを起動してみて,バックエンドがスタート・実行 されるか,簡単にテストしてみてください.
postmaster をデーモンとしてバックグランドで走らせるには、以下のように入力します。
$ cd $ nohup postmaster -i > pgserver.log 2>&1 &
データベースを作成するには、以下のように入力します:
$ createdb
今作成したデータベースに接続してみます:
$ psql
簡単な問い合わせを実行します:
postgres=> SELECT datetime 'now';
psql を終了します:
postgres=> \q
他に使う予定が無ければ、今作ったテスト用のデータベースを削除します:
$ destroydb
postmaster をバックグランドで走らせる場合、Postgres のスーパユーザ(通常は postgres)で行います。絶対に postmaster root アカウントで実行しないで下さい!
普通、システムの起動時に postmaster が自動的に起動するようにすることが出来ますが、これには root 権限は必要ありませんし、またスーパユーザーアカウント以外で Postgres サーバを起動することが出来ます。
以下はいろいろなユーザーから寄せられたサーバの自動起動に関する情報です。
postmaster を自動的に起動させる場合、root ではなく Postgres のスーパユーザ (postgres が使用されていますか?) で起動させること。 それが以下のサンプルスクリプトで、su コマンドでアカウントをpostgresに変更している理由です。以下のコマンドは PATH や PGDATA などの環境変数が正しく設定されないだろう、といったことも考慮しています. 以下のサンプルを使用するに当たっては、十分な注意を払うことをお願いします。
特権を持たないアカウントでインストールし、かつ(あなたが)rootアクセス権を 持たない状態になったら postmaster をバック グラウンドで起動してください
$ cd $ nohup postmaster > regress.log 2>&1 &
NetBSD の rc.local ファイル、あるいは SPARC Solaris 2.5.1 では rc2.d ファイルに以下の内容を1行で追記します:
su postgres -c "/usr/local/pgsql/bin/postmaster -S -D /usr/local/pgsql/data"
FreeBSD 2.2 の場合、/usr/local/etc/rc.d/pgsql.sh に以下を追記し、ファイルモードを 755 (chmod 755)に、オーナーとグループをroot:bin (chown root:bin) に変更します。
#!/bin/sh [ -x /usr/local/pgsql/bin/postmaster ] && { su -l pgsql -c 'exec /usr/local/pgsql/bin/postmaster -D/usr/local/pgsql/data -S -o -F > /usr/local/pgsql/errlog' & echo -n ' pgsql' }上記の起動スクリプトのように途中に改行を加えたとしても、シェルは十分に賢いのでこれを一文とみなして実行することが出来ます。
RedHatLinux の場合、contrib/linux/ にあるサンプルを参考に /etc/rc.d/init.d/postgres.init を作成し、 /etc/rc.d/rc5.d/S98postgres.init からソフトリンクを張ります。
RedHat Linux の場合、/etc/inittab ファイルに以下の内容を一行で追加してください:
pg:2345:respawn:/bin/su - postgres -c "/usr/local/pgsql/bin/postmaster -D/usr/local/pgsql/data >> /usr/local/pgsql/server.log 2>&1 </dev/null"(この例文を書いた作者によると、これはpostmasterが死んでも復活させるとのことですが、他に何か影響が有るかどうかはわからないとのことです。)
regression テストを実行します。 /usr/src/pgsql/src/test/regress/README に 詳しい実行方法と解説が記述されています。 以下は、それを簡略化したものです:
以下を入力します
$ cd /usr/src/pgsql/src/test/regress $ gmake clean $ gmake all runtest
初めて regression テストを実行する場合、gmake clean は入力の必要はありません。
モニター画面への出力と共に ./regress.out というファイルに、 それぞれのテスト結果が記録されます。あるプラットフォーム上では幾つかのテスト結果が "fail"と表示されてしまうことがあります。 予想されるテスト結果と実際のテスト結果の内容が少しでも違った場合、 例えば出力されたエラーメッセージの内容(訳注:わざとエラーになるような テストも行っています)や浮動小数点の丸め方等々で fail が出ることも有ります。 このような種類のエラーは、Postgres の動作に影響を与えません。 ./regression.diffs というテキストファイルには、実際にシステムが 出力したテスト結果と予想されたテスト結果(つまり、基準となる環境で実行されたテスト結果)の 違いが保存されています。それぞれの違いを注意深く調査することにより、重大な問題が発見できるかも 知れません。
i686/Linux-ELF がv6.5.1での regression テスト結果の元になったプラットフォームなので、同一の構成では fail は発生しないと思います。
テスト結果が明らかに問題であっても、特定機種にしか関係の無いことも有ります。 一例として、システムとCコンパイラが 64-bit の整数型をサポートしていない (或いは、configure スクリプトが発見できてなかった)場合には int8 に対するテスト結果は明らかに違ってきますが、64-bitの整数型でデータを保存しなくて 良い場合は、このエラーを無視して構いません。
結論? もし failed というメッセージを見たら、その原因を理解し、それが Postgresを使用する上で影響が有るかを自分で判断することです。 regression テストは有用なテストツールですが、使いこなすには努力が必要です。
regression テストが終了したら、以下のようにしてファイルの後始末をします。
$ destroydb regression $ cd /usr/src/pgsql/src/test/regress $ gmake cleanregression.diffs だけ他のディレクトリに移動しておくと良いかもしれません。
今まで定期メンテナンスを実行していない場合、今がその習慣を打ち破る好機です。 以下の手順は、定期的に実行する必要があります。
最低限のバックアップ手順
VACUUM という SQL コマンドを実行することにより、データベースを整理できます。
(既にいくつかバックアップファイルをお持ちだとは思いますが)システムをバックアップします。できればですが、バックアップ中は他のユーザーがシステムを使用していないことが望まれます。
上記の工程をシェルスクリプトに記述し、cron で毎夜あるいは毎週実行することもできます。 それには先ず、crontab の man ページを読むことが先決です。 (もし、上手くいったらそのシェルスクリプトをメールしてもらえませんか?それを自分も使ってみたいと思います。)
既存のシステムからのアップグレードした場合、以下のようにして古いデータベースを新しいものに取り込みます。
$ cd $ psql -e template1 < db.outv6.2 以前のデータベースで path あるいは polygon geometric のいずれかのデータ型を使用している場合、データ列のアップグレードが必要になります。 psql から、以下のように入力してください。
UPDATE FirstTable SET PathCol = UpgradePath(PathCol); UPDATE SecondTable SET PathCol = UpgradePath(PathCol); ... VACUUM;UpgradePath()はパスの値の整合性を旧構文で確認し,テストにそぐわなければ 列のアップグレードをおこないません. UpgradePoly()はポリゴンが見かけと 違って実際には旧構文からのものなのかどうか,検証できません.しかし間違った アップグレードによる影響を回復させるためにRevertPoly()が用意されています.
もしあなたが Postgres について初心者なら、 以下を試してみると良いかもしれません。
古いシステムを消去する場合、以下のようにします。
$ rm -rf /usr/src/pgsql_6_5 $ rm -rf /usr/local/pgsql_6_5 # 古いデータベースが /usr/local/pgsql_6_5/data に無い場合、 # それの消去も行います。 $ rm ~/postgresql-v6.5.1.tar.gz
マニュアル類を印刷したいと思うかもしれません。 ポストスクリプトプリンタをお持ちかシステムがポストスクリプトファイルを 印刷出来るように設定されている場合、以下のようにして ユーザーズガイドを 印刷できます。
$ cd /usr/local/pgsql/doc $ gunzip user.ps.tz | lpr
以下、Ghostscriptを使用して laserjet プリンタに印刷する場合の手順です。
$ alias gshp='gs -sDEVICE=laserjet -r300 -dNOPAUSE' $ export GS_LIB=/usr/share/ghostscript:/usr/share/ghostscript/fonts $ gunzip user.ps.gz $ gshp -sOUTPUTFILE=user.hp user.ps $ gzip user.ps $ lpr -l -s -r manpage.hp
Postgres を全ての対応済みプラットフォームで動作することが続くようにしたいと思っていますので、動いた、あるいは動かないシステムに関する情報を教えてください。 pgsql-ports@postgresql.orgに下記の情報を書き添えてメールしてください:
Postgres のバージョン。 (例えば、 v6.5.1, 6.5, beta 990318, 等。)
OSの種類。 (例えば、RedHat v5.1 Linux v2.0.34。)
ハードウエアプラットフォームの種類。 (SPARC、i486 等)
コンパイル、インストール、regression test は何事も無く終わりましたか? パッチを当てたとか、自分でソースコードに変更を加えたとか、regression テストで何が失敗したか等の情報を下さい。 ただ、コンパイルの最中にワーニングメッセージが出るのは普通のことなので、それは必要ありません。
さあ、今からはやりたいようにデータベースの作成や操作を行ったり、データベースクライアントプログラムを書いたりして 楽しんで 下さい。