Postgresアーキテクチャの概念

話を続ける前に，まず基本的なPostgresシステム・ アーキテクチャを理解していた方がよいでしょう． Postgresの各部分が，いかにして相互に作用してい るかを理解しておくと，次の章がかなり読みやすくなるでしょう．データベース の専門用語によると，Postgresは「ユーザごとに 処理を行う」クライアント・サーバ・ モデルを用いているということになってい ます．あるPostgresセッションは，以下に示すよう な，互いに 協調する UNIX プロセス群(プログラム)から構成されています．

• 管理デーモン・プロセス(postmaster)

• ユーザのフロントエンド・アプリケーション (例えばpsqlプログラム)

• 1つ以上のバックエンド・データベース・サーバ (postgresプロセス自身)

単一のpostmasterは，単一のホスト上 において， 与えられたデータベースの一群を管理します．そのようなデータベースの一群の ことをインストレーション(installation) とかサイト(site)と呼びます．1つの インストレーション内部において， 与えられたデータベースにアクセスしたいと 思うフロントエンド・ アプリケーションは，ライブラリを呼び出します． ライブラリは，ユーザ の要求をネットワーク経由で postmaster (どのように接続が確立されるか(a)) に送ります。 これを受けて、postmaster は 新しいバックエンド・サーバ・プロセス (どのように接続が確立されるか(b)) を開始させます。

そしてフロントエンドのプロセスを新しいサーバ (どのように接続が確立されるか(c))に 接続します．その時点から，フロントエンドのプロセスとバックエンド サーバは， postmasterの介在なしに通信をします。ですから、 フロントエンドとバックエンドのプロセスが行ったり 来たりしている間にも， postmasterは常に走っていて要求を待っています． libpqライブラリは，ひとつのフロントエンドが バック エンドプロセスに対して複数の接続を行うのを可能にしています．しかし、 フロントエンドアプリケーションは相変わらずシングルスレッド のプロセスです． マルチスレッドのフロントエンド／バックエンドの接続 は，現在のところ libpqではサポートされていません．このアーキテクチャ の1つの実装系では，postmasterとバックエンドは 常に同じマシン(データベースサーバ)で 走っていますが，フロントエンド アプリケーションはどこででも走らせることができます． このことは心に留めておいてください．なぜなら，クライアントマシンから アクセスできるファイルは，データベースサーバ マシンではアクセスできない (もしくは違うファイル名を用いてアクセスできるだけ)かもしれないからです。 また、postmasterと Postgres のサーバが， Postgresの "スーパーユーザ" のユーザIDで走る ことにも気を付けてください． Postgresの スーパーユーザは，特別なユーザ (例えば "postgres" という名前のユーザ) である必要はないことに注意しましょう． 多くのシステムがそのようにインストールされてますが。 さらに，Postgresのスーパーユーザは，絶対にUNIX のスーパーユーザ("root") であってはなりません ! どのような場合でも， データベースに関連する すべてのファイルは，この Postgresのスーパーユーザに属していなければなりません。