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