diff options
Diffstat (limited to 'doc/src/sgml/arch-pg.sgml')
| -rw-r--r-- | doc/src/sgml/arch-pg.sgml | 83 |
1 files changed, 83 insertions, 0 deletions
diff --git a/doc/src/sgml/arch-pg.sgml b/doc/src/sgml/arch-pg.sgml new file mode 100644 index 00000000000..5a22fd36e71 --- /dev/null +++ b/doc/src/sgml/arch-pg.sgml @@ -0,0 +1,83 @@ +<Chapter> + <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> |