mirror of https://github.com/postgres/postgres
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
88 lines
3.5 KiB
88 lines
3.5 KiB
<Chapter Id="arch">
|
|
<TITLE>Architecture</TITLE>
|
|
|
|
<Sect1 id="arch-concepts">
|
|
<Title><ProductName>Postgres</ProductName> Architectural Concepts</Title>
|
|
|
|
<Para>
|
|
Before we begin, you should understand the basic
|
|
<ProductName>Postgres</ProductName> system architecture. Understanding how the
|
|
parts of <ProductName>Postgres</ProductName> interact will make the next chapter
|
|
somewhat clearer.
|
|
In database jargon, <ProductName>Postgres</ProductName> uses a simple "process
|
|
per-user" client/server model. A <ProductName>Postgres</ProductName> session
|
|
consists of the following cooperating Unix processes (programs):
|
|
</Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
<Para>
|
|
A supervisory daemon process (<Application>postmaster</Application>),
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
<Para>
|
|
the user's frontend application (e.g., the <Application>psql</Application> program), and
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
<Para>
|
|
the one or more backend database servers (the <Application>postgres</Application> process itself).
|
|
</Para>
|
|
</ListItem>
|
|
</ItemizedList>
|
|
|
|
<Para>
|
|
A single <Application>postmaster</Application> manages a given collection of
|
|
databases on a single host. Such a collection of
|
|
databases is called a cluster (of databases). Frontend
|
|
applications that wish to access a given database
|
|
within a cluster make calls to the library.
|
|
The library sends user requests over the network to the
|
|
<Application>postmaster</Application> (<XRef LinkEnd="ARCH-CLIENTSERVER">),
|
|
which in turn starts a new backend server process
|
|
|
|
<Figure Id="ARCH-CLIENTSERVER">
|
|
<Title>How a connection is established</Title>
|
|
<Graphic Align="center" FileRef="clientserver.gif" Format="GIF"></Graphic>
|
|
</Figure>
|
|
|
|
and connects the
|
|
frontend process to the new server. From
|
|
that point on, the frontend process and the backend
|
|
server communicate without intervention by the
|
|
<Application>postmaster</Application>. Hence, the <Application>postmaster</Application> is always running, waiting
|
|
for requests, whereas frontend and backend processes
|
|
come and go.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <FileName>libpq</FileName> 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 <FileName>libpq</FileName>.
|
|
One implication of this architecture is that the
|
|
<Application>postmaster</Application> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
You should also be aware that the <Application>postmaster</Application> and
|
|
postgres servers run with the user-id of the <ProductName>Postgres</ProductName>
|
|
"superuser." Note that the <ProductName>Postgres</ProductName> superuser does not
|
|
have to be a special user (e.g., a user named
|
|
"postgres"). Furthermore, the <ProductName>Postgres</ProductName> superuser
|
|
should
|
|
definitely not be the Unix superuser ("root")! In any
|
|
case, all files relating to a database should belong to
|
|
this <ProductName>Postgres</ProductName> superuser.
|
|
</Para>
|
|
</sect1>
|
|
</Chapter>
|
|
|