granicus.if.org Git - postgresql/blob - doc/src/sgml/arch-pg.sgml

   1 <Chapter Id="arch-pg">
   2         <TITLE>Architecture</TITLE>
   3
   4 <Sect1 id="arch-pg-concepts">
   5 <Title><ProductName>Postgres</ProductName> Architectural Concepts</Title>
   6
   7 <Para>
   8      Before we begin, you  should  understand  the  basic
   9      <ProductName>Postgres</ProductName>  system  architecture.   Understanding how the
  10      parts of <ProductName>Postgres</ProductName> interact will make the  next  chapter
  11      somewhat clearer.
  12      In  database  jargon,  <ProductName>Postgres</ProductName> uses a simple "process
  13      per-user" client/server model.  A <ProductName>Postgres</ProductName> session
  14      consists of the following cooperating Unix processes (programs):
  15
  16 <ItemizedList>
  17 <ListItem>
  18 <Para>
  19         A supervisory daemon process (the <Application>postmaster</Application>),
  20 </Para>
  21 </ListItem>
  22 <ListItem>
  23 <Para>
  24         the user's frontend application (e.g., the <Application>psql</Application> program), and
  25 </Para>
  26 </ListItem>
  27 <ListItem>
  28 <Para>
  29         one or more backend database servers (the <Application>postgres</Application> process itself).
  30 </Para>
  31 </ListItem>
  32 </ItemizedList>
  33 </para>
  34 <Para>
  35      A single  <Application>postmaster</Application>  manages  a  given  collection  of
  36      databases  on  a  single  host.   Such  a collection of
  37      databases is called a cluster (of databases).   A frontend
  38      application  that  wishes  to  access  a  given database
  39      within a cluster makes calls to an interface library (eg, libpq)
  40      that is linked into the application.
  41      The library sends user requests over the network to the
  42      <Application>postmaster</Application>
  43 (<XRef LinkEnd="PGARCH-CONNECTIONS">(a)),
  44 which in turn  starts  a  new backend  server  process
  45 (<XRef LinkEnd="PGARCH-CONNECTIONS">(b))
  46
  47 <figure id="PGARCH-CONNECTIONS">
  48  <title>How a connection is established</title>
  49
  50  <mediaobject>
  51   <imageobject>
  52    <imagedata align="center" fileref="connections">
  53   </imageobject>
  54  </mediaobject>
  55 </figure>
  56
  57      and connects the frontend process to the new server
  58 (<XRef LinkEnd="PGARCH-CONNECTIONS">(c)).
  59 From that  point  on,  the  frontend process and the backend
  60      server communicate without intervention by the
  61      <Application>postmaster</Application>.   Hence, the <Application>postmaster</Application> is always running, waiting
  62      for connection requests, whereas frontend  and  backend  processes
  63      come  and  go.  The <FileName>libpq</FileName> library allows a single
  64      frontend to make multiple connections to backend processes.
  65      However,  each backend process is a single-threaded process that can
  66      only execute one query at a time; so the communication over any one
  67      frontend-to-backend connection is single-threaded.
  68 </Para>
  69
  70 <Para>
  71      One  implication of this architecture is that the
  72      <Application>postmaster</Application> and the backend always run on the
  73      same machine (the  database  server), while the frontend
  74      application may run  anywhere.   You  should  keep  this
  75      in  mind,
  76      because  the  files  that  can  be accessed on a client
  77      machine may not be accessible (or may only be  accessed
  78      using  a  different  path name)  on  the database server
  79      machine.
  80 </Para>
  81
  82 <Para>
  83      You should also be aware that the <Application>postmaster</Application> and
  84      postgres  servers  run  with  the  user-id  of the <ProductName>Postgres</ProductName>
  85      <quote>superuser</>.
  86 Note that the <ProductName>Postgres</ProductName> superuser does not
  87 have  to  be  any particular user (e.g., a user named
  88 <literal>postgres</literal>), although many systems are installed that way.
  89 Furthermore,  the  <ProductName>Postgres</ProductName>  superuser should
  90 definitely  not  be the Unix superuser, <literal>root</literal>!
  91 It is safest if the <ProductName>Postgres</ProductName>  superuser is an
  92 ordinary, unprivileged user so far as the surrounding Unix system is
  93 concerned.
  94      In any case, all files relating to a database should belong to
  95      this <ProductName>Postgres</ProductName> superuser.
  96 </Para>
  97 </sect1>
  98 </Chapter>