11.1. Postgresの構造的概念

本題に入る前に、先ずPostgresの基本的な 構造的概念を理解することが必要です。 Postgres のパーツがどのように相互作用するかを理解することによって、次の章がより 正確に理解できることでしょう。データベース用語でいうと、 Postgresは「1ユーザに対し1プロセス」の クライアント/サーバモデルを使用しています。Postgres のセッションは次に挙げるUnixプロセス (プログラム)が協力しあって構成されています。

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

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

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

1つのpostmasterは、1つのホスト上のデータベースの集まりを 管理します。そのようなデータベースの集まりは(データベースの)クラスタと呼ばれます。 クラスタの中のデータベースにアクセスしようとするフロントエンドアプリケーションは、 ライブラリを呼び出します。ライブラリはネットワークを介してユーザのリクエストを postmaster(Figure 11-1(a))に送ります。すると postmaster は、代わりに新しいバックエンドサーバプロセス(Figure 11-1(b)) を起動します。

新しいサーバ(Figure 11-1(c))にフロントエンド プロセスを接続します。 ここからは、フロントエンドプロセスとバックエンドサーバは postmasterの介入なしで通信します。 ですから、フロントエンドとバックエンドプロセスが生成/消滅を繰り返す のに対して、postmasterは常にリクエスト を待ちながら稼働しています。libpqライブラリは 1つのフロントエンドがバックエンドプロセスに対して複数の接続を行う ことができます。しかし、フロントエンドアプリケーションは やはりシングルスレッドプロセスです。マルチスレッドのフロントエンド/ バックエンド接続は現在のところlibpqではサポート されていません。この構造が意味することの1つとして、フロントエンド アプリケーションはどこで稼働しても良いのに対し postmasterとバックエンドは常に同じマシン (データベースサーバ)で 稼働しなければいけないということがあります。このことはよく覚えておいてください。 なぜなら、クライアントマシンでアクセスできるファイルでもデータベースサーバマシン にはアクセスできない(もしくは別のファイル名を使わなければアクセスできない)可能性が あるからです。そして更に、postmasterと postgresサーバ はPostgresのユーザID"superuser"を使用することも覚えておいて ください。多くのシステムとは違い、Postgresのスーパーユーザは特別な ユーザ(つまり "postgres"という名前のユーザ)である必要はありません。 更に、Postgresのスーパーユーザは絶対にUnixスーパーユーザの"root"で あってはいけません。どのような場合においても、データベースに関連する全てのファイルは Postgresスーパーユーザのものでなければいけません。