database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Align some terms in arch-dev.sgml to glossary

Browse Source 
This mostly adds links to the glossary to the existing text, instead of
using <firstterm>.  Heikki left this out of 29ad6595ef out of
stylistic concerns; these have since been addressed.

Author: Jürgen Purtz <juergen@purtz.de>
Discussion: https://postgr.es/m/67d7240f-8596-83fc-5e15-af06c128a0f5@purtz.de
This commit is contained in:
Alvaro Herrera
2021-04-05 11:45:17 -04:00
parent a63dd8afe2
commit 6734e80695
1 changed files with 25 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
doc/src/sgml/arch-dev.sgml
View File

@ -27,7 +27,7 @@
<title>The Path of a Query</title>
<para>
Here we give a short overview of the stages a query has to pass
Here we give a short overview of the stages a query has to pass
to obtain a result.
</para>
@ -114,21 +114,25 @@
<title>How Connections Are Established</title>
<para>
<productname>PostgreSQL</productname> is implemented using a
simple <quote>process per user</quote> client/server model. In this model
there is one <firstterm>client process</firstterm> connected to
exactly one <firstterm>server process</firstterm>. As we do not
know ahead of time how many connections will be made, we have to
use a <firstterm>supervisor process</firstterm> (also
<firstterm>master process</firstterm>) that spawns a new
server process every time a connection is requested. This supervisor
process is called <literal>postmaster</literal> and listens at a
specified TCP/IP port for incoming connections. Whenever a request
for a connection is detected the <literal>postmaster</literal>
process spawns a new server process. The server processes
communicate with each other using <firstterm>semaphores</firstterm> and
<firstterm>shared memory</firstterm> to ensure data integrity
throughout concurrent data access.
<productname>PostgreSQL</productname> implements a
<quote>process per user</quote> client/server model.
In this model, every
<glossterm linkend="glossary-client">client process</glossterm>
connects to exactly one
<glossterm linkend="glossary-backend">backend process</glossterm>.
As we do not know ahead of time how many connections will be made,
we have to use a <quote>supervisor process</quote> that spawns a new
backend process every time a connection is requested. This supervisor
process is called
<glossterm linkend="glossary-postmaster">postmaster</glossterm>
and listens at a specified TCP/IP port for incoming connections.
Whenever it detects a request for a connection, it spawns a new
backend process. Those backend processes communicate with each
other and with other processes of the
<glossterm linkend="glossary-instance">instance</glossterm>
using <firstterm>semaphores</firstterm> and
<glossterm linkend="glossary-shared-memory">shared memory</glossterm>
to ensure data integrity throughout concurrent data access.
</para>
<para>
@ -141,11 +145,11 @@
</para>
<para>
Once a connection is established the client process can send a query
to the <firstterm>backend</firstterm> (server). The query is transmitted using plain text,
i.e., there is no parsing done in the <firstterm>frontend</firstterm> (client). The
server parses the query, creates an <firstterm>execution plan</firstterm>,
executes the plan and returns the retrieved rows to the client
Once a connection is established, the client process can send a query
to the backend process it's connected to. The query is transmitted using
plain text, i.e., there is no parsing done in the client. The backend
process parses the query, creates an <firstterm>execution plan</firstterm>,
executes the plan, and returns the retrieved rows to the client
by transmitting them over the established connection.
</para>
</sect1>