Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1su2hn-003ehu-J8 for pgsql-committers@arkaria.postgresql.org; Fri, 27 Sep 2024 04:35:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1su2hm-002euZ-2V for pgsql-committers@arkaria.postgresql.org; Fri, 27 Sep 2024 04:35:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1su2hk-002esS-Qb for pgsql-committers@lists.postgresql.org; Fri, 27 Sep 2024 04:35:45 +0000 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1su2hf-001IeA-El for pgsql-committers@lists.postgresql.org; Fri, 27 Sep 2024 04:35:43 +0000 Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 66429114021D; Fri, 27 Sep 2024 00:35:38 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Fri, 27 Sep 2024 00:35:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1727411738; x=1727498138; bh=krfIXMCId/ kCVfJw1VJcuFMAOG0gIC+ZpwoZGv3HKUA=; b=TnUPcR6ls+aa3tcyG8/oWVCoCf wCro/shyfR2AEq0QiN0wUJwDVdSXbWQGRGwi98l/c7WkLyi8oZ54hPx0mtbHkIA5 eWfVkxMJTo6H2PMbb9HmkZlawQivmvex6yKunUwsexfKE19k4OHqh25c6LgHsoY+ YO/UXwfbdA1YFw/UWIH5AjtGajL/8PdlrWlov2tvd3oXSSMwMDFQb1cOAyGkenlG UJ7juQYQL4a2pkY5lKYhhVaPRyEnxiramz6emQqxIdmy+vS3Re84b850EudABRF1 CEEsgl3EaqndggIB+aOv7fUIuvwdvFTPT7C4GxJQkLtrW4T+U1xfAzKeJN/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1727411738; x=1727498138; bh=krfIXMCId/kCVfJw1VJcuFMAOG0g IC+ZpwoZGv3HKUA=; b=RfZ7Vx6pwvaTbwSgZ2HZz1tgSmHLuy1Z/eG2H0pYMLAk WBOGIQcHJibyxy1hzsKeFCqfLLH47QRMly5nEwKSp6ppZEtnwNrv/7V/jed3pTrQ f9hlo6MfiaRcQoqSUxDZ4jeaoXbPzildMcrjHzYTR7ZVZaqjATcil7MrB5uy80Lo RAeeVk0CoFnqDZ2QjmG/QpwxXIFxbz2IeggG3/4+G78WPTMSBGFupLJLl2HX173l aO1ve9XdHRHzMSk4XaUet1K/lTfR0sPQieyu3XbRdu3Nu4zWSkpka+5CbMFMmmYW lYQEjDIWng/zHgeTfgVV4M+uB58oOpEVF6y2t0llLQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddtkedgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnegfrhhlucfvnfffucdljedtmdenucfjughrpeffhffvvefukfhf gggtuggjsehgtderredttddvnecuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruc eomhhitghhrggvlhesphgrqhhuihgvrhdrgiihiieqnecuggftrfgrthhtvghrnhepteel ieefudffhffhtdetleeggeegfffhkeeuveetiefgudduvedutefggeeivdejnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhes phgrqhhuihgvrhdrgiihiidpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouh htpdhrtghpthhtoheprggvkhhorhhothhkohhvsehgmhgrihhlrdgtohhmpdhrtghpthht ohepphgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhgpdhrtghpthhtoheprghkohhroh htkhhovhesphhoshhtghhrvghsqhhlrdhorhhgpdhrtghpthhtohepphhgshhqlhdqtgho mhhmihhtthgvrhhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i0fe9450f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 27 Sep 2024 00:35:34 -0400 (EDT) Date: Fri, 27 Sep 2024 13:35:23 +0900 From: Michael Paquier To: Alexander Korotkov Cc: Peter Eisentraut , Alexander Korotkov , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Implement pg_wal_replay_wait() stored procedure Message-ID: References: <18c0fa64-0475-415e-a1bd-665d922c5201@eisentraut.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ux2IJytT1P5dprhM" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Ux2IJytT1P5dprhM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 20, 2024 at 03:00:20PM +0300, Alexander Korotkov wrote: > Please, check the attached patchset for implementation of proposed approach. 0001 looks like it requires an indentation in its .h diffs. +typedef enum +{ + WaitLSNResultSuccess, /* Target LSN is reached */ + WaitLSNResultTimeout, /* Timeout occured */ Perhaps use WAIT_LSN_RESULT_SUCCESS, etc, rather than camel casing. + * Results statuses for WaitForLSNReplay(). Too much plural here. What you are doing with WaitForLSNReplay() sounds kind of right. rc = WaitLatch(MyLatch, wake_events, delay_ms, WAIT_EVENT_WAIT_FOR_WAL_REPLAY); Question about this existing bit in waitlsn.c. Shouldn't this issue a FATAL if rc reports a WL_POSTMASTER_DEATH? Or am I missing an intention here. That was already the case before this patch set. pg_wal_replay_wait() is new to v18, meaning that we still have some time to agree on its final shape for this release cycle. This discussion shares similarities with the recent exercise done in f593c5517d14, and I think that we should be more consistent between both to not repeat the same mistakes as in the past, even if this case if more complex because we have more reasons behind why a wait could not have happened. I would suggest to keep things simple and have one single function rather than introduce two more pg_proc entries with slight differences in their error reporting, making the original function return a text about the reason of the failure when waiting (be it a timeout, success, promotion or outside recovery). FWIW, I am confused regarding the need for WaitLSNResultNotInRecovery and WaitLSNResultPromotedConcurrently in the error states. On a code basis, they check the same thing: RecoveryInProgress(). I'd suggest to cut one of them. This also points to the fact that WaitForLSNReplay() has some duplication that's not required. We could have less GetXLogReplayRecPtr() calls and do all the checks in the for loop. The current structure of the code in waitlsn.c is more complex than it could be. -- Michael --Ux2IJytT1P5dprhM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmb2NgsACgkQnvQgOdby QH3rMRAAnUEvRU4xb7aKR56yLNC77updeBGe/avsn5cjqHdj0UDSwhEyZhdEjpAt 9N0QvCEsHLrYIcnnkSi4B9kEV6IwNZdTsAEmQzTeaOoYAr9AmM7UfYtK1wAhd53N KAHmoxE50DBA0pUa9vwCutTsu3pxRXeeeXBmf4WuWo6dRTXRRzSWNPofeTjoiTaM hQcMK21g6v7egOUI2ouc+5GlrBRlQ/dkUwlyx5gbqKUXov/MINtNKwXDIUQlUptH wA/42ZC1HN9IQqOv2mNMtHTcdvwL9NsFkZ6Y4xQcU1qUorC9KiAlUr2yyz3fuTwK 28JPcgPgEM6urZ8MTg7nHRNrRswSLla0GDmjVgvtkOYr00OOYQrg6Cwz5I/IOGKx cuyKr6g1E/S3PIb5W2PXY3EobGE3Lop3rAnJlL7cM2QF1A0D+CIF964ydZBIoqo4 9NQnVybLCJ75gS5rNlom/3ScV/N2Sw91tOUd44cdIJlnfY/Z4UAuktbhrl55rJcl uSDMcwUI96j8NgGEzm5KQaEYA2V+04wL92nVdngvn29g2WiE7x3f6Q5pnLI9WkaF PkIdtNQqk9hhIaTSAtk02VXSIyuMzv0B6I5ogaPKXqMck2n8Nc6vVtXCA8Y2Lb1Z DflSf4Ycue8lX0Wfc63XA7wjNrKpyjNYqv0zKEmAN2b4XoVGQa4= =YaqN -----END PGP SIGNATURE----- --Ux2IJytT1P5dprhM--