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 1riHzB-00GDC5-Nz for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2024 17:56:54 +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 1riHzA-007c8C-0z for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2024 17:56:52 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riHz9-007c84-OF for pgsql-hackers@lists.postgresql.org; Thu, 07 Mar 2024 17:56:52 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riHz5-003Lql-VG for pgsql-hackers@postgresql.org; Thu, 07 Mar 2024 17:56:50 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 461A25C0058; Thu, 7 Mar 2024 12:56:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 07 Mar 2024 12:56:48 -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=fm1; t=1709834208; x= 1709920608; bh=JFq8zAL7/p+gxBtj3LblZQWmLxG/sEMivp2fOdQD4AI=; b=k 1V0nwLJuhFd9gUQESJXGTw6GOc+1EnyiWg24epxXlNNKrlLcH+h5xGqtbIJRsDOI VTh8UjcS0fVbAuRg1B//pbOBNihOZwUxhmy1r4cw8ziSnCdz9h0aEhYuHnzUqsd3 Y/VYFmBi4QRzu1Fv6961EOAhKTw/1jovNfRisODBmjsU54rSFy4zXNTZfrV1/rbD ymjQ1YOXHwhDE6hH3ly4aWtQrb5rne3v/w7nlBfucNEgzGHIVDAaWJHyHadGQYTi 6ifH/xyH3akEIMtTOdYYFqQWMPNVzlfPDvcmodL0BplJAX2rErpNut1bKGuLALxk l8iz7a9YHoczE8JiGTWng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrieefgddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepffeujeehgeefieeigfeljeefveduueetiefhjeefteej keelieehvefgjeekjedunecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh dpghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 7 Mar 2024 12:56:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1709834206; bh=2ao1xZ3s2K8XeHNGtYQzkrWoPFnK1XBd3d834mzYwU0=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=nHf4L4G1dmHulFOTd9ZEIpsB+XO8A8Ler/NE31RZEJtUmCXhU9bJVhvkWCCnnkesj kOYUwfR8GQVgVNH+SU7ubvvFm1YKuI2Nb7VBGWiI/JeUy5AxJvehPJkd4pnIg8yL3v DpRKOVu+I2Hopa2a5mT5xKnagSwuSvoIUaWu5K2wTgVKY/D0o9roqW3GCNJJAeTojK /nWF/NNOfTH3gLQnJapGn6C9a2BMbh/aHmsiYn2LHibLB3QcW6PoKo17E0fqtqKFS6 U+iI8RHyTqhp/cv+ko32rLugbnlsEjcMbBTDck5LJzK7Wl4wrFWGn5+ZpDxb1FztIr k8F4bNCjIJIyQ== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 74C13D84; Thu, 7 Mar 2024 18:56:46 +0100 (CET) Date: Thu, 7 Mar 2024 18:56:46 +0100 From: Alvaro Herrera To: Antonin Houska Cc: Pavel Stehule , Michael Paquier , PostgreSQL Hackers Subject: Re: why there is not VACUUM FULL CONCURRENTLY? Message-ID: <202403071756.f55kh6tj6bmf@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6347.1708105409@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024-Feb-16, Antonin Houska wrote: > BTW, I'm failing to understand why cluster_rel() has no argument of the > BufferAccessStrategy type. According to buffer/README, the criterion for using > specific strategy is that page "is unlikely to be needed again > soon". Specifically for cluster_rel(), the page will *definitely* not be used > again (unless the VACCUM FULL/CLUSTER command fails): BufferTag contains the > relatin file number and the old relation file is eventually dropped. > > Am I missing anything? No, that's just an oversight. Access strategies are newer than that cluster code. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Most hackers will be perfectly comfortable conceptualizing users as entropy sources, so let's move on." (Nathaniel Smith) https://mail.gnu.org/archive/html/monotone-devel/2007-01/msg00080.html