Subject: Re: Additional Chapter for Tutorial - arch-dev.sgml
To: Erik Rijkers <er@xs4all.nl>, =?UTF-8?Q?J=c3=bcrgen_Purtz?=
 <juergen@purtz.de>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Justin Pryzby <pryzby@telsasoft.com>
References: <13c65997-9502-7671-1a7b-50e5d5093514@purtz.de>
 <93fd8e15-8639-23c8-c7c4-d4cfca323189@purtz.de>
 <CAKFQuwZ_USvnhZ5wQLFtpr8v+iMiwvZOiVZhviQwPYGDVR7w+g@mail.gmail.com>
 <32c7ebc0-f69f-8a77-c397-8fcb9139d8d3@purtz.de>
 <CAKFQuwbqiZ4Er_e21oXt8J_JDyNucLMcW7murkMr0v=pTy10RA@mail.gmail.com>
 <CAKFQuwbtReW3dBO0HmZCb8rF4z-w+oFt24nPko8pbAk4Y2VWEw@mail.gmail.com>
 <779bb812-5238-f78b-2782-b1d990f952e3@purtz.de>
 <f13dcc2a57d4ce05ce1e83aa2f94396e@xs4all.nl>
 <7a081d6c-e288-615c-f32c-839fb27366ed@purtz.de>
 <c5328f092e9f6b05c0061d6f1842cc4a@xs4all.nl>
 <da4037ea-cf9f-0461-17c0-aeac257cedf4@purtz.de>
 <759f7a615736d8066b3441571d371c68@xs4all.nl>
 <de79497b-b498-bea7-8651-0f2e6f5037b0@purtz.de>
 <99f58c4752e9984ffe38a4343fed3837@xs4all.nl>
 <1bfb1ae4-6f5b-bff4-15a8-a768e0ddd450@purtz.de>
 <CAKFQuwaEp3HRgB=C3CfqLWsHqH3p_kmow+n+ERuaCRR=ozt0nw@mail.gmail.com>
 <b4124734-9d3f-849d-b408-b122b624772c@purtz.de>
 <b20470f4662c322ad0dc142dd32b3246@xs4all.nl>
From: Heikki Linnakangas <hlinnaka@iki.fi>
Message-ID: <aa31f359-1168-ded5-53d0-0ed228bfe097@iki.fi>
Date: Mon, 18 Jan 2021 16:13:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <b20470f4662c322ad0dc142dd32b3246@xs4all.nl>
Content-Type: multipart/mixed;
 boundary="------------28F45D019EBB9A9D3573B8B5"
Content-Language: en-US
Precedence: bulk

This is a multi-part message in MIME format.
--------------28F45D019EBB9A9D3573B8B5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 20/11/2020 23:52, Erik Rijkers wrote:
> (smallish) Changes to arch-dev.sgml

This looks good to me. One little complaint:

> @@ -125,7 +122,7 @@
>      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>postgres</literal> and listens at a
> +    process is called <literal>postgres</literal> (formerly 'postmaster') and listens at a
>      specified TCP/IP port for incoming connections. Whenever a request
>      for a connection is detected the <literal>postgres</literal>
>      process spawns a new server process. The server tasks

I believe we still call it the postmaster process. We renamed the binary 
a long time ago (commit 5266f221a2), and the above text was changed as 
part of that commit. I think that was a mistake, and this should say simply:

... This supervisor process is called <literal>postmaster</literal> and ...

like it did before we renamed the binary.

Barring objections, I'll commit this with that change (as attached).

- Heikki

--------------28F45D019EBB9A9D3573B8B5
Content-Type: text/x-patch; charset=UTF-8;
 name="arch-dev.sgml.20210118-heikki.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="arch-dev.sgml.20210118-heikki.diff"

diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml
index ade0ad97d8..a27c8477c2 100644
--- a/doc/src/sgml/arch-dev.sgml
+++ b/doc/src/sgml/arch-dev.sgml
@@ -7,7 +7,7 @@
    <title>Author</title>
    <para>
     This chapter originated as part of
-    <xref linkend="sim98"/>, Stefan Simkovics'
+    <xref linkend="sim98"/> Stefan Simkovics'
     Master's Thesis prepared at Vienna University of Technology under the direction
     of O.Univ.Prof.Dr. Georg Gottlob and Univ.Ass. Mag. Katrin Seyr.
    </para>
@@ -17,10 +17,7 @@
    This chapter gives an overview of the internal structure of the
    backend of <productname>PostgreSQL</productname>.  After having
    read the following sections you should have an idea of how a query
-   is processed. This chapter does not aim to provide a detailed
-   description of the internal operation of
-   <productname>PostgreSQL</productname>, as such a document would be
-   very extensive. Rather, this chapter is intended to help the reader
+   is processed.  This chapter is intended to help the reader
    understand the general sequence of operations that occur within the
    backend from the point at which a query is received, to the point
    at which the results are returned to the client.
@@ -30,8 +27,8 @@
    <title>The Path of a Query</title>
 
    <para>
-    Here we give a short overview of the stages a query has to pass in
-    order to obtain a result.
+    Here we give a short overview of the stages a query has to pass 
+    to obtain a result.
    </para>
 
    <procedure>
@@ -125,9 +122,9 @@
     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>postgres</literal> and listens at a
+    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>postgres</literal>
+    for a connection is detected the <literal>postmaster</literal>
     process spawns a new server process. The server tasks
     communicate with each other using <firstterm>semaphores</firstterm> and
     <firstterm>shared memory</firstterm> to ensure data integrity
@@ -230,7 +227,7 @@
     <para>
      A detailed description of <application>bison</application> or
      the grammar rules given in <filename>gram.y</filename> would be
-     beyond the scope of this paper. There are many books and
+     beyond the scope of this manual. There are many books and
      documents dealing with <application>flex</application> and
      <application>bison</application>. You should be familiar with
      <application>bison</application> before you start to study the
@@ -343,8 +340,8 @@
    <note>
     <para>
      In some situations, examining each possible way in which a query
-     can be executed would take an excessive amount of time and memory
-     space. In particular, this occurs when executing queries
+     can be executed would take an excessive amount of time and memory.
+     In particular, this occurs when executing queries
      involving large numbers of join operations. In order to determine
      a reasonable (not necessarily optimal) query plan in a reasonable amount
      of time, <productname>PostgreSQL</productname> uses a <firstterm>Genetic
@@ -411,7 +408,7 @@
         <firstterm>merge join</firstterm>: Each relation is sorted on the join
         attributes before the join starts. Then the two relations are
         scanned in parallel, and matching rows are combined to form
-        join rows. This kind of join is more
+        join rows. This kind of join is
         attractive because each relation has to be scanned only once.
         The required sorting might be achieved either by an explicit sort
         step, or by scanning the relation in the proper order using an
@@ -442,7 +439,7 @@
      If the query uses fewer than <xref linkend="guc-geqo-threshold"/>
      relations, a near-exhaustive search is conducted to find the best
      join sequence.  The planner preferentially considers joins between any
-     two relations for which there exist a corresponding join clause in the
+     two relations for which there exists a corresponding join clause in the
      <literal>WHERE</literal> qualification (i.e., for
      which a restriction like <literal>where rel1.attr1=rel2.attr2</literal>
      exists). Join pairs with no join clause are considered only when there

--------------28F45D019EBB9A9D3573B8B5--