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ü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".

> 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