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 1pwgSp-0004dk-SK for pgsql-hackers@arkaria.postgresql.org; Wed, 10 May 2023 09:50:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pwgSo-0003zN-QX for pgsql-hackers@arkaria.postgresql.org; Wed, 10 May 2023 09:50:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pwgSo-0003zE-G6 for pgsql-hackers@lists.postgresql.org; Wed, 10 May 2023 09:50:26 +0000 Received: from new4-smtp.messagingengine.com ([66.111.4.230]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pwgSh-001kNR-Fd for pgsql-hackers@postgresql.org; Wed, 10 May 2023 09:50:25 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 1B809580A7A for ; Wed, 10 May 2023 05:50:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 10 May 2023 05:50:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1683712217; x=1683719417; bh=KNKpDiFGKjDzU AvGa4FnLix75UPoUTW58qhdE/oP/1U=; b=XVY3+EeideWWMHYK9/3tS/wFTsJqH w2+GkQs7cwTOAnFvck5ZUm98/wK+UORMHupwZZrPPZZ+/844QbLCOIH4J/2plDGS nhc9nGiObNyUHC9owAWyBLPKpdHRcvoEpqcDPBTLzce11L8flr4AKOKT2LTl9o98 to9RP9m1OVRtYw8L8j3EBHldKgA9v0QAgoMtdMeq0/40WN02zBqW8cc3nd96t8yq Kd8xg8Z7IGHFnJJ/GGQzUj37QC6KVmywQLWlwuuje85RU1+jauJJrONjtA7jLQ55 RvfPCC3kuzDBlgBvSWfM+nhvI4y5Zq7lMbbAoQ39hKhlgfQlRSe+t197Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeeghedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfhuffvtgfgsehtjeertd dtfeejnecuhfhrohhmpefrvghtvghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgv ihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhmqeenucggtffrrghtth gvrhhnpeeijeeuveeghfeiteettdegtdevhfdvleduleevveegleevtdelueehteevffdt ueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvg htvghrrdgvihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 10 May 2023 05:50:16 -0400 (EDT) Message-ID: <22fed8ba-01c3-2008-a256-4ea912d68fab@enterprisedb.com> Date: Wed, 10 May 2023 11:50:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Content-Language: en-US From: Peter Eisentraut Subject: smgrzeroextend clarification To: pgsql-hackers Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I was looking at the new smgrzeroextend() function in the smgr API. The documentation isn't very extensive: /* * smgrzeroextend() -- Add new zeroed out blocks to a file. * * Similar to smgrextend(), except the relation can be extended by * multiple blocks at once and the added blocks will be filled with * zeroes. */ The documentation of smgrextend() is: /* * smgrextend() -- Add a new block to a file. * * The semantics are nearly the same as smgrwrite(): write at the * specified position. However, this is to be used for the case of * extending a relation (i.e., blocknum is at or beyond the current * EOF). Note that we assume writing a block beyond current EOF * causes intervening file space to become filled with zeroes. */ So if you want to understand what smgrzeroextend() does, you need to mentally combine the documentation of three different functions. Could we write documentation for each function that stands on its own? And document the function arguments, like what does blocknum and nblocks mean? Moreover, the text "except the relation can be extended by multiple blocks at once and the added blocks will be filled with zeroes" doesn't make much sense as a differentiation, because smgrextend() does that as well. AFAICT, the differences between smgrextend() and smgrzeroextend() are: 1. smgrextend() writes a payload block in addition to extending the file, smgrzeroextend() just extends the file without writing a payload. 2. smgrzeroextend() uses various techniques (posix_fallocate() etc.) to make sure the extended space is actually reserved on disk, smgrextend() does not. #1 seems fine, but the naming of the APIs does not reflect that at all. If we think that #2 is important, maybe smgrextend() should do that as well? Or at least explain why it's not needed?