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 1p03U1-0007g0-7F for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Nov 2022 16:29:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p03U0-0002N5-44 for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Nov 2022 16:29:20 +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 1p03Tz-0002MZ-Qf for pgsql-hackers@lists.postgresql.org; Tue, 29 Nov 2022 16:29:19 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p03Tx-000557-GY for pgsql-hackers@lists.postgresql.org; Tue, 29 Nov 2022 16:29:18 +0000 Received: from bruce by momjian.us with local (Exim 4.94.2) (envelope-from ) id 1p03Tt-001NMO-WE; Tue, 29 Nov 2022 11:29:14 -0500 Date: Tue, 29 Nov 2022 11:29:13 -0500 From: Bruce Momjian To: SATYANARAYANA NARLAPURAM Cc: Bharath Rupireddy , Andrey Borodin , Kyotaro Horiguchi , Laurenz Albe , PostgreSQL Hackers Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication Message-ID: References: <20220805.114916.994654810780821553.horikyota.ntt@gmail.com> <20220809.161236.1486509314201074910.horikyota.ntt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM wrote: > 2. Process proc die immediately when a backend is waiting for sync > replication acknowledgement, as it does today, however, upon restart, > don't open up for business (don't accept ready-only connections) > unless the sync standbys have caught up. > > > Are you planning to block connections or queries to the database? It would be > good to allow connections and let them query the monitoring views but block the > queries until sync standby have caught up. Otherwise, this leaves a monitoring > hole. In cloud, I presume superusers are allowed to connect and monitor (end > customers are not the role members and can't query the data). The same can't be > true for all the installations. Could you please add more details on your > approach? I think ALTER SYSTEM should be allowed, particularly so you can modify synchronous_standby_names, no? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Embrace your flaws. They make you human, rather than perfect, which you will never be.