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 1mVasb-0005ob-W9 for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Sep 2021 14:48:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mVasa-0003r4-W3 for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Sep 2021 14:48:16 +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 1mVasa-0003qw-Nu for pgsql-hackers@lists.postgresql.org; Wed, 29 Sep 2021 14:48:16 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVasY-0002to-DZ for pgsql-hackers@lists.postgresql.org; Wed, 29 Sep 2021 14:48:15 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 89E125C01DA; Wed, 29 Sep 2021 10:48:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 29 Sep 2021 10:48:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=K5EUslZW/7YAGCkQOztd0vizNgsM1ND6gX0FYlJOxdw=; b=Gabwj/MY kAL+B9GR0ItaasaHGd8kPzEDIir7ENq2UvqoMHXyHJczqqR5DKjONXA4mnWtOuIq aRreUadG41Xe0mGWj+LDPGU6YcXYCnMTXYbkEhDoc29SLcqGtGAw9mzM1hieYlJc g5xxGoQcGMnz0kfQsahqYOyowmEhoc9ODEr1vB77KfjcPMHmCI4lLQONF+n6AcxC +ZA7HNOAUrrq/+mR+Y6Fg4pPzFNveGIeJjM06UnKnRk0spJ7dqgEdAv6yCZ3a6XT r+enyWZQTGZbZN06bHBdWvhZtgNRlpYhyklDf63R/H93ep+Iyp7WDzZqvKE//Iq+ WWr+/SSSe7zmrg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekvddgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 29 Sep 2021 10:48:13 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 0D4F72A06AB; Wed, 29 Sep 2021 11:48:11 -0300 (-03) Date: Wed, 29 Sep 2021 11:48:11 -0300 From: Alvaro Herrera To: Hannu Krosing Cc: "Bossart, Nathan" , Kyotaro Horiguchi , "andres@anarazel.de" , "masao.fujii@oss.nttdata.com" , "pgsql-hackers@lists.postgresql.org" , "mengjuan.cmj@alibaba-inc.com" , "Jakub.Wartak@tomtom.com" , Ryo Matsumura Subject: Re: prevent immature WAL streaming Message-ID: <202109291448.55jfdijip2cr@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Sep-24, Hannu Krosing wrote: Hi Hannu > In the first email you write > > > As mentioned in the course of thread [1], we're missing a fix for > streaming replication to avoid sending records that the primary hasn't > fully flushed yet. This patch is a first attempt at fixing that problem > by retreating the LSN reported as FlushPtr whenever a segment is > registered, based on the understanding that if no registration exists > then the LogwrtResult.Flush pointer can be taken at face value; but if a > registration exists, then we have to stream only till the start LSN of > that registered entry. > > So did we end up holding back the wal_sender to not send anything that > is not confirmed as flushed on master No. We eventually realized that that approach was a dead end, so I abandoned the whole thing and attacked the problem differently. So your other questions don't apply. I tried to make the commit message explain both the problem and the solution in as much detail as possible; please have a look at that and let me know if something is unclear. Thanks -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "El miedo atento y previsor es la madre de la seguridad" (E. Burke)