Postgresアーキテクチャの概念

Before we continue, you should understand the basic Postgres system architecture. Understanding how the parts of Postgres interact will make the next chapter somewhat clearer. In database jargon, Postgres uses a simple "process per-user" client/server model. A Postgres session consists of the following cooperating UNIX processes (programs):

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

• A supervisory daemon process (postmaster),

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

• the user's frontend application (e.g., the psql program), and

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

• the one or more backend database servers (the postgres process itself).

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

A single postmaster manages a given collection of databases on a single host. Such a collection of databases is called an installation or site. Frontend applications that wish to access a given database within an installation make calls to the library. The library sends user requests over the network to the postmaster (どのように接続が確立されるか(a)), which in turn starts a new backend server process (どのように接続が確立されるか(b))

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

and connects the frontend process to the new server (どのように接続が確立されるか(c)). From that point on, the frontend process and the backend server communicate without intervention by the postmaster. Hence, the postmaster is always running, waiting for requests, whereas frontend and backend processes come and go. The libpq library allows a single frontend to make multiple connections to backend processes. However, the frontend application is still a single-threaded process. Multithreaded frontend/backend connections are not currently supported in libpq. One implication of this architecture is that the postmaster and the backend always run on the same machine (the database server), while the frontend application may run anywhere. You should keep this in mind, because the files that can be accessed on a client machine may not be accessible (or may only be accessed using a different filename) on the database server machine. You should also be aware that the postmaster and postgres servers run with the user-id of the Postgres "superuser." Note that the Postgres superuser does not have to be a special user (e.g., a user named "postgres"), although many systems are installed that way. Furthermore, the Postgres superuser should definitely not be the UNIX superuser, "root"! In any case, all files relating to a database should belong to this Postgres superuser. そしてフロントエンドのプロセスを新しいサーバ (どのように接続が確立されるか(c))に 接続します．その時点から，フロントエンドのプロセスとバックエンド サーバは， postmasterの介在なしに通信をします。ですから、 フロントエンドとバックエンドのプロセスが行ったり 来たりしている間にも， postmasterは常に走っていて要求を待っています． libpqライブラリは，ひとつのフロントエンドが バック エンドプロセスに対して複数の接続を行うのを可能にしています．しかし、 フロントエンドアプリケーションは相変わらずシングルスレッド のプロセスです． マルチスレッドのフロントエンド／バックエンドの接続 は，現在のところ libpqではサポートされていません．このアーキテクチャ の1つの実装系では，postmasterとバックエンドは 常に同じマシン(データベースサーバ)で 走っていますが，フロントエンド アプリケーションはどこででも走らせることができます． このことは心に留めておいてください．なぜなら，クライアントマシンから アクセスできるファイルは，データベースサーバ マシンではアクセスできない (もしくは違うファイル名を用いてアクセスできるだけ)かもしれないからです。 また、postmasterと Postgres のサーバが， Postgresの "スーパーユーザ" のユーザIDで走る ことにも気を付けてください． Postgresの スーパーユーザは，特別なユーザ (例えば "postgres" という名前のユーザ) である必要はないことに注意しましょう． 多くのシステムがそのようにインストールされてますが。 さらに，Postgresのスーパーユーザは，絶対にUNIX のスーパーユーザ("root") であってはなりません ! どのような場合でも， データベースに関連する すべてのファイルは，この Postgresのスーパーユーザに属していなければなりません。