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 1jlrtW-0001mg-2V for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2020 10:35: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 1jlrsz-00086V-2o for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2020 10:35:09 +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 1jlrsy-00086M-OJ for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2020 10:35:08 +0000 Received: from mail.dalibo.com ([212.85.157.172]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jlrsw-000688-BC for pgsql-hackers@postgresql.org; Thu, 18 Jun 2020 10:35:07 +0000 Received: from firost (larco.ioguix.net [82.66.0.6]) by mail.dalibo.com (Postfix) with ESMTPSA id 258AE222DC; Thu, 18 Jun 2020 12:35:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dalibo.com; s=a; t=1592476504; bh=Msaiyjy81+jwOc1gpf/cbboMF710sWoYoWZjgxkzQpQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YLDnXYq3Ir2creWO20vNiTyvQKnfzmBnVtHv7q7ABqn9kmqXU+aiEO+wdeNTMhTrv O/vmwVaD8FYB3FvB9eMfLSmHmeXgghR92koIkuSG+APftIMm4mlyKAsbuHr4GAq8JV LY5x/MTpYaLBvyVDfdXXq9S9MBZ0A8n9H7OeMfvg= Date: Thu, 18 Jun 2020 12:35:03 +0200 From: Jehan-Guillaume de Rorthais To: Robert Haas Cc: Tom Lane , Amit Kapila , amul sul , PostgreSQL-development Subject: Re: [Patch] ALTER SYSTEM READ ONLY Message-ID: <20200618123503.4d2c5ae5@firost> In-Reply-To: References: <1445158.1592405895@sss.pgh.pa.us> Organization: Dalibo MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, 17 Jun 2020 12:07:22 -0400 Robert Haas wrote: [...] > > Commands that involve a whole > > bunch of subtle interlocking --- and, therefore, aren't going to work if > > anything has gone wrong already anywhere in the server --- seem like a > > particularly poor thing to be hanging your HA strategy on. > > It's important not to conflate controlled switchover with failover. > When there's a failover, you have to accept some risk of data loss or > service interruption; but a controlled switchover does not need to > carry the same risks and there are plenty of systems out there where > it doesn't. Yes. Maybe we should make sure the wording we are using is the same for everyone. I already hear/read "failover", "controlled failover", "switchover" or "controlled switchover", this is confusing. My definition of switchover is: swapping primary and secondary status between two replicating instances. With no data loss. This is a controlled procedure where all steps must succeed to complete. If a step fails, the procedure fail back to the original primary with no data loss. However, Wikipedia has a broader definition, including situations where the switchover is executed upon a failure: https://en.wikipedia.org/wiki/Switchover Regards,