mirror of
https://github.com/postgres/postgres.git
synced 2025-12-22 17:42:17 +03:00
84 lines
3.7 KiB
Plaintext
84 lines
3.7 KiB
Plaintext
<Chapter Id="arch-pg">
|
|
<TITLE>Architecture</TITLE>
|
|
|
|
<Sect1>
|
|
<Title><ProductName>Postgres</ProductName> Architectural Concepts</Title>
|
|
|
|
<Para>
|
|
Before we continue, 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):
|
|
|
|
<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>
|
|
<Para>
|
|
A single <Application>postmaster</Application> 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
|
|
<Application>postmaster</Application>
|
|
(<XRef LinkEnd="PGARCH-CONNECTIONS" EndTerm="PGARCH-CONNECTIONS">(a)),
|
|
which in turn starts a new backend server process
|
|
(<XRef LinkEnd="PGARCH-CONNECTIONS" EndTerm="PGARCH-CONNECTIONS">(b))
|
|
|
|
<Figure Id="PGARCH-CONNECTIONS">
|
|
<Title>How a connection is established</Title>
|
|
<Graphic Align="center" FileRef="connections.gif" Format="GIF"></Graphic>
|
|
</Figure>
|
|
|
|
and connects the frontend process to the new server
|
|
(<XRef LinkEnd="PGARCH-CONNECTIONS" EndTerm="PGARCH-CONNECTIONS">(c)).
|
|
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. 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.
|
|
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"), although many systems are installed that way.
|
|
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>
|