Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.
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):
A supervisory daemon process (postmaster),
the user's frontend application (e.g., the psql program), and
the one or more backend database servers (the postgres process itself).
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
(How a connection is established(a)),
which in turn starts a new backend server process
(How a connection is established(b))
and connects the frontend process to the new server
(How a connection is established(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.
