diff options
Diffstat (limited to 'doc/src/sgml/arch.sgml')
| -rw-r--r-- | doc/src/sgml/arch.sgml | 88 |
1 files changed, 0 insertions, 88 deletions
diff --git a/doc/src/sgml/arch.sgml b/doc/src/sgml/arch.sgml deleted file mode 100644 index d420fab6dd..0000000000 --- a/doc/src/sgml/arch.sgml +++ /dev/null @@ -1,88 +0,0 @@ -<Chapter Id="arch"> - <TITLE>Architecture</TITLE> - -<Sect1 id="arch-concepts"> -<Title><ProductName>Postgres</ProductName> Architectural Concepts</Title> - -<Para> - Before we begin, 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): -</Para> - -<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 a cluster (of databases). Frontend - applications that wish to access a given database - within a cluster make calls to the library. - The library sends user requests over the network to the - <Application>postmaster</Application> (<XRef LinkEnd="ARCH-CLIENTSERVER">), - which in turn starts a new backend server process - -<Figure Id="ARCH-CLIENTSERVER"> -<Title>How a connection is established</Title> -<Graphic Align="center" FileRef="clientserver.gif" Format="GIF"></Graphic> -</Figure> - - and connects the - frontend process to the new server. 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. -</Para> - -<Para> - 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. -</Para> - -<Para> - 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> -</sect1> -</Chapter> |