Re: Add A Glossary

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Jürgen Purtz <juergen(at)purtz(dot)de>, pgsql-hackers(at)postgresql(dot)org, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Roger Harkavy <rogerharkavy(at)gmail(dot)com>
Subject: Re: Add A Glossary
Date: 2020-05-19 06:17:26
Message-ID: 39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

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

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Andrew Grillet 2020-05-19 06:44:57 Re: Add A Glossary
Previous Message Michael Paquier 2020-05-19 02:49:18 Re: Missing comma?

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-05-19 06:20:29 Re: Missing grammar production for WITH TIES
Previous Message Michael Paquier 2020-05-19 06:13:13 Re: could not stat promote trigger file leads to shutdown