Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jbN3Z-0000Y7-UY for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2020 11:38:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jbN3Y-000097-9C for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2020 11:38:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jbN3X-00008y-7D for pgsql-hackers@lists.postgresql.org; Wed, 20 May 2020 11:38:39 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jbN3S-0002QF-6W for pgsql-hackers@postgresql.org; Wed, 20 May 2020 11:38:37 +0000 Received: by mail-ed1-x52b.google.com with SMTP id d24so2718120eds.11 for ; Wed, 20 May 2020 04:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=n+DVLLBg8ZrqBFL5EJ7COF7CyYW/CoFsPYdNwTEDqM4=; b=0obo9+Gb2Fc9kUsXGHIZIWuouqo+KEgX3mz6Q6e0gptW4jW9kwguNp/Q6oD6cIQ59x /mUYDAinTPE/bQ2qwiijW06aqHfe6EzwZrxEXwAupq82XcQ065lGrs+gCvpMry8JZlol K0j8BmtsOAj87AyGAFplQ1IOaqALxictBgLreYM5jHS7zhSOvG9aIgxjRXttzMb42KC2 lqJWRHEu2j6EkMrPc3/sj6RDVLVNHnL8C3f7p0US49XHMLO7Vm7+1cuaLE6VwAePmCze JyrmaptEZmi1d+TVuPZ5e5sRBXCWWxna6aLS4NdNPOguPK69yEhaZVdFRap2FMGao85f 8lAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=n+DVLLBg8ZrqBFL5EJ7COF7CyYW/CoFsPYdNwTEDqM4=; b=mfdcdsuOrM/sspyedG8YYvqVzWv1bbxusYTH+VVMkZqACjQqcO99VuDRJb3isAYQyN rqHIeUXWwWIOOVF8vaaKziLdVxjgJrTtShX0AVDHwvO6UMoTMARyndjKLG8re3CJzFdV cNkPUOyCycCmZcYEoFoSpSPEjZt6Az8hSs2xy/HtUw/dJYjpQic2okVpweuuX9TWC3oi yphoO/Hug7x+oiUf36FQSXQtwy39eRDQQ4FteJKhgwEInNFNu4967rqX8u0lc+53sBgY xbY3P6yEdnKjbm+AP9pbCUGXQoCattGUbewLQlta/1ouuaGgVKJNeR1dA5yc6HieV81P UfMw== X-Gm-Message-State: AOAM530F29AdDn7k7kHU4T3B3CDSguvzNkPSNTcFxa5SHYlr0rB0vuSn QRxPQw0YG5lv3V8IkoqStAhPOQ== X-Google-Smtp-Source: ABdhPJwARexFiCcPBx9mM/nrK3BvxTgLYQNSCURGNfVmXamDXEpOJuMGlIRzLTzlYlIqsKM6gLyYag== X-Received: by 2002:a05:6402:709:: with SMTP id w9mr2866791edx.255.1589974710633; Wed, 20 May 2020 04:38:30 -0700 (PDT) Received: from dynamic-eotlmt57cxwt1wzm9-pd01.res.v6.highway.a1.net (dynamic-eotlmt57cxwt1wzm9-pd01.res.v6.highway.a1.net. [2001:871:60:b467:23a6:b9e0:a2d5:f151]) by smtp.gmail.com with ESMTPSA id k2sm1727859ejv.71.2020.05.20.04.38.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2020 04:38:29 -0700 (PDT) Message-ID: Subject: Re: Add A Glossary From: Laurenz Albe To: =?ISO-8859-1?Q?J=FCrgen?= Purtz , pgsql-hackers@postgresql.org, Pg Docs Cc: Erik Rijkers , Fabien COELHO , Corey Huinker , Justin Pryzby , Roger Harkavy Date: Wed, 20 May 2020 13:38:28 +0200 In-Reply-To: <838c8e85-f3fe-dc68-9367-b413e167578d@purtz.de> References: <20200517152851.GA31376@alvherre.pgsql> <39586b2ad7ee14a50fd3aacdc412b6d826da0039.camel@cybertec.at> <838c8e85-f3fe-dc68-9367-b413e167578d@purtz.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, 2020-05-20 at 13:17 +0200, Jürgen Purtz wrote: > > 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. I think that the "pg_ctl" example does not apply: It does not talk about starting the cluster, but about starting the server process, that is "server" in the way I understand it. > 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.) That does not feel right to me. "cluster server", ouch. "databases server", ouch as well. I never felt the term "cluster" was unclear in these contexts. Sometimes it means "data directory", sometimes it is used for "server process", but I think few people would think one cound connect to a data directory or create a process in a directory (initdb). I think clarity is a Good Thing, but it can be overdone. > > > 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". You are most thorough :^) > 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 port is a server? No way. > A - possibly virtualized - machine It might be good to disambiguate that, but I don't think that the PostgreSQL documentation should use the word "server" to mean "machine". > An abbreviation for the slightly longer term > "database(s)/cluster server" ??? this will support the > readability, but not the clarity ??? "Server" is short for "database server" and is a set of processes that listen for and handle incoming database client requests. I think that covers all the meanings you quoted from the documentation, except c), where it is used as shorthand for "server executable". Yours, Laurenz Albe