11.1. Postgresの構造的概念

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

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

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

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

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

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