2.1. Postgresの構造的概念

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

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

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

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

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

そして新しいサーバにフロントエンドプロセスを接続します。 ここからは、フロントエンドプロセスとバックエンドサーバは postmasterの介入なしで連絡をとりあいます。 ですから、フロントエンドとバックエンドプロセスが生成/削減を繰り返す のに対して、postmasterは常にリクエスト を待ちながら稼働しています。

libpqライブラリは 一つのフロントエンドがバックエンドプロセスに対して複数の接続を行う ことを許可します。しかし、フロントエンドアプリケーションは やはりシングルスレッドプロセスです。マルチスレッドの フロントエンド/ バックエンド接続は現在のところlibpqではサポート されていません。この構造が意味することの一つとして、フロントエンド アプリケーションはどこで稼働しても良いのに対しポストマスター とバックエンドは常に同じマシン(データベースサーバ)で 稼働しなければいけないということがあります。このことはよく覚えておいて ください。 なぜなら、クライアントマシンでアクセスできるファイルでもデータベース サーバマシンにはアクセスできない(もしくは別のファイル名を使わなければ アクセスできない)可能性があるからです。

そして更に、postmasterと postgres サーバー はPostgresのユーザID"superuser"を使うことも 覚えておいてください。多くのシステムとは違い、 Postgresのスーパーユーザは特別な ユーザ(例えば"postgres"という名前のユーザ)である必要はありません。 更に、Postgresのスーパーユーザは絶対にUnix スーパーユーザの"root"であるべきではありません。どのような場合においても、 データベースに関連する全てのファイルはPostgres スーパーユーザのものであってはいけません。