arch-pg.sgml

<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>