MIME-Version: 1.0
References: <20200517152851.GA31376@alvherre.pgsql>
 <e32802cd-7795-f3c5-db66-0e262b232132@purtz.de>
 <39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at>
In-Reply-To: <39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at>
From: Andrew Grillet <andrew@grillet.co.uk>
Date: Tue, 19 May 2020 07:44:57 +0100
Message-ID: 
 <CAC-wiJWmvNHdM9jsZ+_PXMfiW59hBbWg1WmAmi0UwPc0WvVYPA@mail.gmail.com>
Subject: Re: Add A Glossary
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: =?UTF-8?Q?J=C3=BCrgen_Purtz?= <juergen@purtz.de>,
	pgsql-hackers@postgresql.org, Pg Docs <pgsql-docs@lists.postgresql.org>,
	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>
Content-Type: multipart/alternative; boundary="000000000000da3fd005a5fa9e7f"
Precedence: bulk

--000000000000da3fd005a5fa9e7f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think there needs to be a careful analysis of the language and a formal
effort to stabilise it for the future.

In the context of, say, an Oracle T series, which is partitioned into
multiple domains (virtual machines) in it, each
of these has multiple CPUs, and can run an instance of the OS which hosts
multiple virtual instances
of the same or different OSes. Som domains might do this while others do
not!

A host could be a domain, one of many virtual machines, or it could be one
of many hosts on that VM
but even these hosts could be virtual machines that each runs several
virtual servers!

Of course, PostgreSQL can run on any tier of this regime, but the
documentation at least needs to be consistent
about language.

A "machine" should probably refer to hardware, although I would accept that
a domain might count as "virtual
hardware" while a host should probably refer to a single instance of OS.

Of course it is possible for a single  instance of OS to run multiple
instances of PostgreSQL, and people do this. (I have
in the past).

Slightly more confusingly, it would appear possible for a single instance
of an OS to have multiple IP addresses
and if there are multiple instances of PostgreSQL, they may serve different
IP Addresses uniquely, or
share them. I think this case suggests that a host probably best describes
an OS instance. I might be wrong.

The word "server" might be an instance of any of the above, or a waiter
with a bowl of soup. It is best
reserved for situations where clarity is not required.

If you are new to all this, I am sure it is very confusing, and
inconsistent language is not going to help.

Andrew


AFAICT


On Tue, 19 May 2020 at 07:17, Laurenz Albe <laurenz.albe@cybertec.at> wrote=
:

> On Mon, 2020-05-18 at 18:08 +0200, J=C3=BCrgen 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 exist=
s
> > 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".
>
> > 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).
>
> Yours,
> Laurenz Albe
>
>
>
>

--000000000000da3fd005a5fa9e7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think there needs to be a careful analysis of the l=
anguage and a formal effort to stabilise it for the future.</div><div><br><=
/div><div>In the context of, say, an Oracle T series, which is partitioned =
into multiple domains (virtual machines) in it, each</div><div>of these has=
 multiple CPUs, and can run an instance of the OS which hosts multiple virt=
ual instances<br></div><div>of the same or different OSes. Som domains migh=
t do this while others do not!<br></div><div><br></div><div>A host could be=
 a domain, one of many virtual machines, or it could be one of many hosts o=
n that VM</div><div>but even these hosts could be virtual machines that eac=
h runs several virtual servers!</div><div><br></div><div>Of course, Postgre=
SQL can run on any tier of this regime, but the documentation at least need=
s to be consistent<br></div><div>about language. <br></div><div><br></div><=
div>A &quot;machine&quot; should probably refer to hardware, although I wou=
ld accept that a domain might count as &quot;virtual <br></div><div>hardwar=
e&quot; while a host should probably refer to a single instance of OS. <br>=
</div><div><br></div><div>Of course it is possible for a single=C2=A0 insta=
nce of OS to run multiple instances of PostgreSQL, and people do this. (I h=
ave</div><div>in the past).</div><div><br></div><div>Slightly more confusin=
gly, it would appear possible for a single instance of an OS to have multip=
le IP addresses</div><div>and if there are multiple instances of PostgreSQL=
, they may serve different IP Addresses uniquely, or <br></div><div>share t=
hem. I think this case suggests that a host probably best describes an OS i=
nstance. I might be wrong.<br></div><div><br></div><div>The word &quot;serv=
er&quot; might be an instance of any of the above, or a waiter with a bowl =
of soup. It is best</div><div>reserved for situations where clarity is not =
required. <br></div><div><br></div><div>If you are new to all this, I am su=
re it is very confusing, and inconsistent language is not going to help.</d=
iv><div><br></div><div>Andrew<br></div><div><br></div><div><br></div><div><=
br></div><div>AFAICT<br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, 19 May 2020 at 07:17, Laurenz Albe &lt;<a href=3D"m=
ailto:laurenz.albe@cybertec.at">laurenz.albe@cybertec.at</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2020-05-18 =
at 18:08 +0200, J=C3=BCrgen Purtz wrote:<br>
&gt; cluster/instance: PG (mainly) consists of a group of processes that co=
mmonly<br>
&gt; act on shared buffers. The processes are very closely related to each =
other<br>
&gt; and with the buffers. They exist altogether or not at all. They use a =
common<br>
&gt; initialization file and are incarnated by one command. Everything exis=
ts<br>
&gt; solely in RAM and therefor has a fluctuating nature. In summary: they =
build<br>
&gt; a unit and this unit needs to have a name of itself. In some pages we =
used<br>
&gt; to use the term *instance* - sometimes in extended forms: *database in=
stance*,<br>
&gt; *PG instance*, *standby instance*, *standby server instance*, *server =
instance*,<br>
&gt; or *remote instance*.=C2=A0 For me, the term *instance* makes sense, t=
he extensions<br>
&gt; *standby instance* and *remote instance* in their context too.<br>
<br>
FWIW, I feel somewhat like Alvaro on that point; I use those terms synonymo=
usly,<br>
perhaps distinguishing between a &quot;started cluster&quot; and a &quot;st=
opped cluster&quot;.<br>
After all, &quot;cluster&quot; refers to &quot;a cluster of databases&quot;=
, which are there, regardless<br>
if you start the server or not.<br>
<br>
The term &quot;cluster&quot; is unfortunate, because to most people it sugg=
ests a group of<br>
machines, so the term &quot;instance&quot; is better, but that ship has sai=
led long ago.<br>
<br>
The static part of a cluster to me is the &quot;data directory&quot;.<br>
<br>
&gt; server/host: We need a term to describe the underlying hardware respec=
tively<br>
&gt; the virtual machine or container, where PG is running. I suggest to us=
e both<br>
&gt; *server* and *host*. In computer science, both have their eligibility =
and are<br>
&gt; widely used. Everybody understands *client/server architecture* or *ho=
st* in<br>
&gt; TCP/IP configuration. We cannot change such matter of course. I sugges=
t to<br>
&gt; use both depending on the context, but with the same meaning: &quot;re=
al hardware,<br>
&gt; a container, or a virtual machine&quot;.<br>
<br>
On this I have a strong opinion because of my Unix mindset.<br>
&quot;machine&quot; and &quot;host&quot; are synonyms, and it doesn&#39;t m=
atter to the database if they<br>
are virtualized or not.=C2=A0 You can always disambiguate by adding &quot;v=
irtual&quot; or &quot;physical&quot;.<br>
<br>
A &quot;server&quot; is a piece of software that responds to client request=
s, never a machine.<br>
In my book, this is purely Windows jargon.=C2=A0 The term &quot;client-serv=
er architecture&quot;<br>
that you quote emphasized that.<br>
<br>
Perhaps &quot;machine&quot; would be the preferable term, because &quot;hos=
t&quot; is more prone to<br>
misunderstandings (except in a networking context).<br>
<br>
Yours,<br>
Laurenz Albe<br>
<br>
<br>
<br>
</blockquote></div>

--000000000000da3fd005a5fa9e7f--