From: =?UTF-8?Q?J=c3=bcrgen_Purtz?= <juergen@purtz.de>
Subject: Re: Add A Glossary
To: Laurenz Albe <laurenz.albe@cybertec.at>, pgsql-hackers@postgresql.org,
 Pg Docs <pgsql-docs@lists.postgresql.org>
Cc: Erik Rijkers <er@xs4all.nl>, Fabien COELHO <coelho@cri.ensmp.fr>,
 Corey Huinker <corey.huinker@gmail.com>, Justin Pryzby
 <pryzby@telsasoft.com>, Roger Harkavy <rogerharkavy@gmail.com>
References: <20200517152851.GA31376@alvherre.pgsql>
 <e32802cd-7795-f3c5-db66-0e262b232132@purtz.de>
 <39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at>
Message-ID: <838c8e85-f3fe-dc68-9367-b413e167578d@purtz.de>
Date: Wed, 20 May 2020 13:17:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at>
Content-Type: multipart/alternative;
 boundary="------------37AC58D180AE5FE02EE74AB6"
Content-Language: en-US
Precedence: bulk

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

On 19.05.20 08:17, Laurenz Albe wrote:
> On Mon, 2020-05-18 at 18:08 +0200, Jürgen Purtz wrote:
>> cluster/instance: PG (mainly) consists of a group of processes that commonly
>> act on shared buffers. The processes are very closely related to each other
>> and with the buffers. They exist altogether or not at all. They use a common
>> initialization file and are incarnated by one command. Everything exists
>> solely in RAM and therefor has a fluctuating nature. In summary: they build
>> a unit and this unit needs to have a name of itself. In some pages we used
>> to use the term *instance* - sometimes in extended forms: *database instance*,
>> *PG instance*, *standby instance*, *standby server instance*, *server instance*,
>> or *remote instance*.  For me, the term *instance* makes sense, the extensions
>> *standby instance* and *remote instance* in their context too.
> FWIW, I feel somewhat like Alvaro on that point; I use those terms synonymously,
> perhaps distinguishing between a "started cluster" and a "stopped cluster".
> After all, "cluster" refers to "a cluster of databases", which are there, regardless
> if you start the server or not.
>
> The term "cluster" is unfortunate, because to most people it suggests a group of
> machines, so the term "instance" is better, but that ship has sailed long ago.
>
> The static part of a cluster to me is the "data directory".

cluster/instance: The different nature (static/dynamic) of what I call 
"cluster" and "instance" as well as the existence of the two commands 
"initdb — create a new PostgreSQL database cluster" and "pg_ctl — 
initialize, start, stop, or control a PostgreSQL server" confirms me in 
my opinion that we need two different terms for them. Those two terms 
shall not be synonym to each other, they label distinct things. If 
people prefer "data directory" instead of "cluster", this is ok for me.

There are situations where we need a single term for both of them. 
"Instance and its data directory" or "Instance and its cluster" are too 
wordy. In many cases we use "database server" or "server" in this sense. 
Imo "Server" is too short and ambiguous. "database server", the plural 
form "databases server", or the new term "cluster server", which is more 
accurate, would be ok for me. (Similar to "server", the term "cluster" 
is also used in many different contexts - but only outside of the PG 
world; within our context "cluster" is not ambiguous.)

>> server/host: We need a term to describe the underlying hardware respectively
>> the virtual machine or container, where PG is running. I suggest to use both
>> *server* and *host*. In computer science, both have their eligibility and are
>> widely used. Everybody understands *client/server architecture* or *host* in
>> TCP/IP configuration. We cannot change such matter of course. I suggest to
>> use both depending on the context, but with the same meaning: "real hardware,
>> a container, or a virtual machine".
> On this I have a strong opinion because of my Unix mindset.
> "machine" and "host" are synonyms, and it doesn't matter to the database if they
> are virtualized or not.  You can always disambiguate by adding "virtual" or "physical".
>
> A "server" is a piece of software that responds to client requests, never a machine.
> In my book, this is purely Windows jargon.  The term "client-server architecture"
> that you quote emphasized that.
>
> Perhaps "machine" would be the preferable term, because "host" is more prone to
> misunderstandings (except in a networking context).
>
server/host: I agree that we are not interested in the question whether 
there is real hardware or any virtualization container. We are even not 
interested in the operating system. Our primary concern is the existence 
of a port of the Internet Protocol. But is the term "server" appropriate 
to name an IP-port? Additionally, "server" is used for other meanings: 
a) the previously mentioned "database server" b) a (virtual) machine: 
"server-side", "... the file ... loaded by the server ..." c) binaries 
"... the server must be built with SSL support ..." d) whenever it seems 
to be appropriate: "standby server", "... the server parses query ...", 
"server configuration", "server process".

Because of its ambiguous usage, the definition of "server" must clarify 
the allowed meanings. What's about:

--

server: Depending on the context, the term *server* denotes:

  * An IP-port which is offered by any OS.   ?????
  * A - possibly virtualized - machine
  * An abbreviation for the slightly longer term "database(s)/cluster
    server"  ??? this will support the readability, but not the clarity ???
  * More ?

--

The term "host" is used mainly for IP configuration "host name", "host 
address" and in the context of compiling "host language", "host 
variable". These are clear situations and can be defined easily.


--------------37AC58D180AE5FE02EE74AB6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 19.05.20 08:17, Laurenz Albe wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at">
      <pre class="moz-quote-pre" wrap="">On Mon, 2020-05-18 at 18:08 +0200, Jürgen Purtz wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">cluster/instance: PG (mainly) consists of a group of processes that commonly
act on shared buffers. The processes are very closely related to each other
and with the buffers. They exist altogether or not at all. They use a common
initialization file and are incarnated by one command. Everything exists
solely in RAM and therefor has a fluctuating nature. In summary: they build
a unit and this unit needs to have a name of itself. In some pages we used
to use the term *instance* - sometimes in extended forms: *database instance*,
*PG instance*, *standby instance*, *standby server instance*, *server instance*,
or *remote instance*.  For me, the term *instance* makes sense, the extensions
*standby instance* and *remote instance* in their context too.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">FWIW, I feel somewhat like Alvaro on that point; I use those terms synonymously,
perhaps distinguishing between a "started cluster" and a "stopped cluster".
After all, "cluster" refers to "a cluster of databases", which are there, regardless
if you start the server or not.

The term "cluster" is unfortunate, because to most people it suggests a group of
machines, so the term "instance" is better, but that ship has sailed long ago.

The static part of a cluster to me is the "data directory".</pre>
    </blockquote>
    <p>cluster/instance: The different nature (static/dynamic) of what I
      call "cluster" and "instance" as well as the existence of the two
      commands "initdb — create a new PostgreSQL database cluster" and 
      "pg_ctl — initialize, start, stop, or control a PostgreSQL server"
      confirms me in my opinion that we need two different terms for
      them. Those two terms shall not be synonym to each other, they
      label distinct things. If people prefer "data directory" instead
      of "cluster", this is ok for me.</p>
    <p>There are situations where we need a single term for both of
      them. "Instance and its data directory" or "Instance and its
      cluster" are too wordy. In many cases we use "database server" or
      "server" in this sense. Imo "Server" is too short and ambiguous.
      "database server", the plural form "databases server", or the new
      term "cluster server", which is more accurate, would be ok for me.
      (Similar to "server", the term "cluster" is also used in many
      different contexts - but only outside of the PG world; within our
      context "cluster" is not ambiguous.) <br>
    </p>
    <blockquote type="cite"
      cite="mid:39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at">
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">server/host: We need a term to describe the underlying hardware respectively
the virtual machine or container, where PG is running. I suggest to use both
*server* and *host*. In computer science, both have their eligibility and are
widely used. Everybody understands *client/server architecture* or *host* in
TCP/IP configuration. We cannot change such matter of course. I suggest to
use both depending on the context, but with the same meaning: "real hardware,
a container, or a virtual machine".
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">On this I have a strong opinion because of my Unix mindset.
"machine" and "host" are synonyms, and it doesn't matter to the database if they
are virtualized or not.  You can always disambiguate by adding "virtual" or "physical".

A "server" is a piece of software that responds to client requests, never a machine.
In my book, this is purely Windows jargon.  The term "client-server architecture"
that you quote emphasized that.

Perhaps "machine" would be the preferable term, because "host" is more prone to
misunderstandings (except in a networking context).

</pre>
    </blockquote>
    <p>server/host: I agree that we are not interested in the question
      whether there is real hardware or any virtualization container. We
      are even not interested in the operating system. Our primary
      concern is the existence of a port of the Internet Protocol. But
      is the term "server" appropriate to name an IP-port? Additionally,
      "server" is used for other meanings: a) the previously mentioned
      "database server" b) a (virtual) machine: "server-side", "... the
      file ... loaded by the server ..." c) binaries "... the server
      must be built with SSL support ..." d) whenever it seems to be
      appropriate: "standby server", "... the server parses query ...",
      "server configuration", "server process".</p>
    <p>Because of its ambiguous usage, the definition of "server" must
      clarify the allowed meanings. What's about:</p>
    <p>--</p>
    <p>server: Depending on the context, the term *server* denotes:</p>
    <ul>
      <li>An IP-port which is offered by any OS.   ?????<br>
      </li>
      <li>A - possibly virtualized - machine</li>
      <li>An abbreviation for the slightly longer term
        "database(s)/cluster server"  ??? this will support the
        readability, but not the clarity ???<br>
      </li>
      <li>More ?<br>
      </li>
    </ul>
    <p>--</p>
    <p>The term "host" is used mainly for IP configuration "host name",
      "host address" and in the context of compiling "host language",
      "host variable". These are clear situations and can be defined
      easily.<br>
    </p>
    <br>
  </body>
</html>

--------------37AC58D180AE5FE02EE74AB6--