From: juergen <juergen@purtz.de>
Date: Mon, 5 Apr 2021 14:18:21 +0200
Subject: [PATCH] Aligning terms to Glossary

---
 doc/src/sgml/arch-dev.sgml | 45 ++++++++++++++++++++++----------------
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml
index e56a13283f..3230264d91 100644
--- a/doc/src/sgml/arch-dev.sgml
+++ b/doc/src/sgml/arch-dev.sgml
@@ -114,21 +114,28 @@
    <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
+    <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 <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.
+    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 +148,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 his backend process. 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>
-- 
2.25.1


--------------453EE98D1D20EFA291C4A1FE--