diff options
Diffstat (limited to 'doc/src/sgml/arch-dev.sgml')
| -rw-r--r-- | doc/src/sgml/arch-dev.sgml | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml new file mode 100644 index 00000000000..aa83257a0b2 --- /dev/null +++ b/doc/src/sgml/arch-dev.sgml @@ -0,0 +1,80 @@ +<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="ARCHDEV-CONNECTIONS" EndTerm="ARCHDEV-CONNECTIONS">(a)), which in turn starts a new + backend server process (<XRef LinkEnd="ARCHDEV-CONNECTIONS" EndTerm="ARCHDEV-CONNECTIONS">(b)) + +<Figure id="ARCHDEV-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="ARCHDEV-CONNECTIONS" EndTerm="ARCHDEV-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"). 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> |