mirror of
https://github.com/postgres/postgres.git
synced 2025-08-11 04:22:52 +03:00
contrib
doc
manual
admin.html
advanced.html
appenda.html
architec.html
copy.html
extend.html
figure01.gif
figure02.gif
figure03.gif
intro.html
libpq.html
lobj.html
pg95user.html
query.html
refs.html
rules.html
start.html
xaggr.html
xfunc.html
xindex.html
xoper.html
xtypes.html
FAQ
FAQ-Irix
FAQ-Linux
README.GEQO
README.fsync
README.support
TODO
TODO.GEQO
bug.template
libpgtcl.doc
userguide.ps
migration
src
COPYRIGHT
HISTORY
INSTALL
README
77 lines
3.2 KiB
HTML
77 lines
3.2 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<TITLE>The POSTGRES95 User Manual - ARCHITECTURE</TITLE>
|
|
</HEAD>
|
|
|
|
<BODY>
|
|
|
|
<font size=-1>
|
|
<A HREF="pg95user.html">[ TOC ]</A>
|
|
<A HREF="intro.html">[ Previous ]</A>
|
|
<A HREF="start.html">[ Next ]</A>
|
|
</font>
|
|
<HR>
|
|
<H1>2. POSTGRES ARCHITECTURE CONCEPTS</H1>
|
|
<HR>
|
|
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):
|
|
<UL>
|
|
<LI>A supervisory daemon process (the <B>postmaster</B>),
|
|
<LI>the user's frontend application (e.g., the <B>psql</B> program), and
|
|
<LI>the one or more backend database servers (the <B>postgres</B> process itself).
|
|
</UL>
|
|
A single <B>postmaster</B> 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
|
|
<B>postmaster</B> (Figure 1(a)), which in turn starts a new
|
|
backend server process (Figure 1(b))
|
|
|
|
<IMG SRC="figure01.gif" ALIGN=right ALT="Figure 1- How a connection is established"><br>
|
|
|
|
and connects the
|
|
frontend process to the new server (Figure 1(c)). From
|
|
that point on, the frontend process and the backend
|
|
server communicate without intervention by the
|
|
<B>postmaster</B>. Hence, the <B>postmaster</B> is always running, waiting
|
|
for requests, whereas frontend and backend processes
|
|
come and go. The <B>LIBPQ</B> 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 <B>LIBPQ</B>.
|
|
One implication of this architecture is that the
|
|
<B>postmaster</B> 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 <B>postmaster</B> 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"). 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.
|
|
|
|
<HR>
|
|
<font size=-1>
|
|
<A HREF="pg95user.html">[ TOC ]</A>
|
|
<A HREF="intro.html">[ Previous ]</A>
|
|
<A HREF="start.html">[ Next ]</A>
|
|
</font>
|
|
</BODY>
|
|
</HTML>
|