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 1rUrxg-00DTR0-AW for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jan 2024 17:31:53 +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 1rUrxf-008Xsu-CQ for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jan 2024 17:31:51 +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 1rUrxf-008Xsk-0P for pgsql-hackers@lists.postgresql.org; Tue, 30 Jan 2024 17:31:51 +0000 Received: from wfout3-smtp.messagingengine.com ([64.147.123.146]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rUrxb-004Ywa-V7 for pgsql-hackers@lists.postgresql.org; Tue, 30 Jan 2024 17:31:50 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.west.internal (Postfix) with ESMTP id 5E0581C0007E; Tue, 30 Jan 2024 12:31:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 30 Jan 2024 12:31:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706635903; x= 1706722303; bh=JxISHx3yIwonEjcTy6VMANqcg7pyG4YkyTeJ/fbzciE=; b=O NZorph/zv0dsIRUUG5fZWxr6W8N2lo1RIL0logCy+FjwmUxZsZEkpLQIdGMhPYXk t6scKbgOEsjK4CeqsL/hmRUkqQFdYEqtEfeB2EZDFvm+5tBSLdEMPY9JIvjWa4Ce XXwm3JsP98IfE988k+q/WxQ7YIXElGomdIh03mdiLQhIIRmRi6oqVuqzaxeB9OdF C/swjSxYdi+gIaFqSP565yd6x6MH1MDePWwjpqxhjY7c/Pxzp3XHFQoR8Rd0LcOO 4dwDeL+KiG0VhuZoNa3AdaVAqKh06zCtpTdDhM08/eqCmLEEq/3Nf6D0owjJyabI Zw1FFvScKG+LyBsPfpfCw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedtjedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 30 Jan 2024 12:31:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1706635901; bh=GffcTyHTxrfXCGdIIWGErPaPSiVTuKa6f98h0H57Gsk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=c2tLK/UTnTAzv6FyL2PYE2wUud2yo/Z9+61ppf/ctCiTc/WSSDP6E6O2JdL32eWGx JQh9PY2wHy279txZJKXnUhME41iEzmoMncge1DXdo8jO3wltzCSsoSMe+CHn5wxM6J 0zNVVxwdBz3K1dSvTpWSmhXSPhSo2UHt186lwBTNQrbk+6ywR1Y9C9dCb0f0ivweCY 41ZLiRIVjY2SIuQVhr+kXR3oYDuYic/t75oMkphETSse4smzwBDtI3LvknIbalYx4g /iAd8MDbKmr+V6nqfj+1DrMWpSVOZB5pddt5WPBak9GdiD9p9T6+B3BvvKaME8Egk2 MQb1ZA9XfgVNA== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id C3AC78B; Tue, 30 Jan 2024 18:31:41 +0100 (CET) Date: Tue, 30 Jan 2024 18:31:41 +0100 From: Alvaro Herrera To: Bharath Rupireddy Cc: Jeff Davis , Andres Freund , Dilip Kumar , Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org, Nathan Bossart , Masahiko Sawada Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible Message-ID: <202401301731.o3cthlcry4ve@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 Hmm, this looks quite nice and simple. My only comment is that a sequence like this /* Read from WAL buffers, if available. */ rbytes = XLogReadFromBuffers(&output_message.data[output_message.len], startptr, nbytes, xlogreader->seg.ws_tli); output_message.len += rbytes; startptr += rbytes; nbytes -= rbytes; if (!WALRead(xlogreader, &output_message.data[output_message.len], startptr, leaves you wondering if WALRead() should be called at all or not, in the case when all bytes were read by XLogReadFromBuffers. I think in many cases what's going to happen is that nbytes is going to be zero, and then WALRead is going to return having done nothing in its inner loop. I think this warrants a comment somewhere. Alternatively, we could short-circuit the 'if' expression so that WALRead() is not called in that case (but I'm not sure it's worth the loss of code clarity). Also, but this is really quite minor, it seems sad to add more functions with the prefix XLog, when we have renamed things to use the prefix WAL, and we have kept the old names only to avoid backpatchability issues. I mean, if we have WALRead() already, wouldn't it make perfect sense to name the new routine WALReadFromBuffers? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Tiene valor aquel que admite que es un cobarde" (Fernandel)