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 1mAaNo-0007Rt-9S for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Aug 2021 16:01:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mAaNm-00084s-9g for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Aug 2021 16:01:38 +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 1mAaNm-00084k-1e for pgsql-hackers@lists.postgresql.org; Mon, 02 Aug 2021 16:01:38 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mAaNk-0008Qa-1z for pgsql-hackers@postgresql.org; Mon, 02 Aug 2021 16:01:37 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5E0515C01E2; Mon, 2 Aug 2021 12:01:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 02 Aug 2021 12:01:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=fm2; bh=M nayWAu/c5tpJLfB2BVMEw7ESKivqI/pvHVEI6/4NGo=; b=FDkhv/V0ofymVb6nG 3VA6ZA/cHCeJHC58T9yQOEhQnufNlABPemJ/IOo/M/5ZbKt3feHwxVRQSUl4f0Q9 P43zlkcdYr+1yeYhqtO+xvtu+reKMcayfmPSHD5k8cV+C0UdfKkCLUJDLDtwKI4N 1YhlVMqP/8LuQRfbfm9SEmT5206w4dPDkqgvy9HYxM9Det7VjicP9DSS96DguHQk v/QzVjn42NQnXnNmxsm2JScIyaqnqnbE1XZC6S0ifLqtJeXBf3Yr0IpVtYtbLVh+ U2KgxD1g4YjbZcck0YHHQ1sPAlhaJfCj/yNn0w/HDCxemcaj7a2pR0thtxTRuo4q I2L/Q== 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:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=MnayWAu/c5tpJLfB2BVMEw7ESKivqI/pvHVEI6/4N Go=; b=TpkLdHzUuFP+Oxgd/kFFN5mpbNx0KqT6F2akBD8R4EXAzplqf9lvnmUDG n9XV6b+wpJxpxAN9WBQLDVYPwJvQYtm+pbIEfKMSk4oj58xd9Oap4bMyKlrvfTqG BHmIsvB2GipDgFIEe/P4LDjyGnN5BEUn42/NSb5+0JeH7bUvXQ+KBE0wVfTlEQLl WFzgsk7vtCDXWJu2Ib6jqAivikM86kDtl2VTr4iIm2CS6pcFLBp29iT9mP2D5QHY Ntm4hGB9IF8rVHWzgf7Gofm1umvLGzRlae/DGMUK/SPKHHkxncfnOwG5KDfmpnk2 Z3O2OtLAwmZHC5B2HN2DCdB58Sk6g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddriedvgdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtffrrg htthgvrhhnpeeiudeujefhueefffffffekiedthfelueffueelhfekheeujefffefghfff ffetffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Aug 2021 12:01:34 -0400 (EDT) Date: Mon, 2 Aug 2021 09:01:33 -0700 From: Andres Freund To: "Drouvot, Bertrand" Cc: Ibrar Ahmed , Amit Khandekar , fabriziomello@gmail.com, Alvaro Herrera , tushar , "[pgdg] Robert Haas" , Rahila Syed , pgsql-hackers Subject: Re: Minimal logical decoding on standbys Message-ID: <20210802160133.uugcce5ql4m5mv5m@alap3.anarazel.de> References: <20210407170954.xbovgh3xdrnogg7w@alap3.anarazel.de> <20210407203218.pestfxu7watrnog4@alap3.anarazel.de> <20210408034713.auf7oaxyymu2kc7n@alap3.anarazel.de> <26c6f320-98f0-253c-f8b5-df1e7c1f6315@amazon.com> <8d263a6b-a99f-0f9b-43ba-e8967c386f2b@amazon.com> <2feee395-959b-6d53-369a-c00f8f2fa6c5@amazon.com> <20210727172257.ekvkspdqaeh2etfg@alap3.anarazel.de> <69aad0bf-697a-04e1-df6c-0920ec8fa528@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <69aad0bf-697a-04e1-df6c-0920ec8fa528@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2021-08-02 16:45:23 +0200, Drouvot, Bertrand wrote: > On 7/27/21 7:22 PM, Andres Freund wrote: > > On 2021-07-27 09:23:48 +0200, Drouvot, Bertrand wrote: > > > Thanks for the warning, rebase done and new v21 version attached. > > Did you have a go at fixing the walsender race conditions I > > (re-)discovered? Without fixing those I don't see this patch going in... > > Those new patches should be addressing all your previous code and TAP tests > remarks, except those 2 for which I would need your input: > > 1. The first one is linked to your remarks: > " > > > While working on this I found a, somewhat substantial, issue: > > > > When the primary is idle, on the standby logical decoding via walsender > > will typically not process the records until further WAL writes come in > > from the primary, or until a 10s lapsed. > > > > The problem is that WalSndWaitForWal() waits for the *replay* LSN to > > increase, but gets woken up by walreceiver when new WAL has been > > flushed. Which means that typically walsenders will get woken up at the > > same time that the startup process will be - which means that by the > > time the logical walsender checks GetXLogReplayRecPtr() it's unlikely > > that the startup process already replayed the record and updated > > XLogCtl->lastReplayedEndRecPtr. > > > > I think fixing this would require too invasive changes at this point. I > > think we might be able to live with 10s delay issue for one release, but > > it sure is ugly :(. > > This is indeed pretty painful. It's a lot more regularly occuring if you > either have a slot disk, or you switch around the order of > WakeupRecovery() and WalSndWakeup() XLogWalRcvFlush(). > > " > > Is that what you are referring to as the “walsender race conditions”? Yes. > If so, do you already have in mind a way to handle this? (I thought you > already had in mind a way to handle it so the question) Yes. I think we need to add a condition variable to be able to wait for WAL positions to change. Either multiple condition variables (one for the flush position, one for the replay position), or one that just changes more often. That way one can wait for apply without a race condition. > 2. The second one is linked to your remark: > > "There's also no test 
for a recovery conflict due to row removal" > > Don't you think that the 
"vacuum full" conflict test is enough? It's not. It'll cause conflicts due to exclusive locks etc. > if not, what kind of additional 
tests would you like to see? A few catalog rows being removed (e.g. due to DELETE and then VACUUM *without* full) and a standby without hot_standby_feedback catching that. Greetings, Andres Freund