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 1pnMWP-0005aT-Vs for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Apr 2023 16:43:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pnMWO-0004AU-KR for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Apr 2023 16:43:36 +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 1pnMWO-0004AK-B7 for pgsql-hackers@lists.postgresql.org; Fri, 14 Apr 2023 16:43:36 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pnMWL-002tSi-5W; Fri, 14 Apr 2023 16:43:35 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A49F95C0139; Fri, 14 Apr 2023 12:43:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 14 Apr 2023 12:43:31 -0400 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:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1681490611; x= 1681577011; bh=pC/PJPXjCIxaUhx+1mRghcn1gd27pskAVgiuNkhCsGA=; b=j dYo/tz3OJXQxVL85N1Bzi6bc+8qQ8nSKDRwFz2Ni+DhZSI6c+Vz8K8UBGFhiNJt3 XH6BCme1ZsOXjxli6hXl8BmZ8ABlBewfVOhsYhXl48GlpcMVSE21MZ09ACYDGBoF Za2y1hEf2ZlIAEWNmC6p3KSEqtGYy8fU8PxOMVwNmo3QK9CpWnYZ7g/r0V2U3XBZ TB7x0NF2hu545W+NT0ng6y9i8irSlWv8Doi1c+qW6Sn6l0L5+CMQGNEuwiqN3ybr IGpRQKZIMRPD1WgJadLchEZNUiLupc/4YJK4tT9Mrrp7CwKkzqOQfhf6yIZ2qHBl MJUqot7HiR498YtDs984Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeltddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeej keffgfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl vhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Apr 2023 12:43:30 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 065F1A1; Fri, 14 Apr 2023 18:43:29 +0200 (CEST) Date: Fri, 14 Apr 2023 18:43:29 +0200 From: Alvaro Herrera To: Greg Stark Cc: "Jonathan S. Katz" , Robert Haas , Laurenz Albe , Amit Kapila , Andres Freund , Justin Pryzby , pgsql-hackers@postgresql.org Subject: Re: Should we remove vacuum_defer_cleanup_age? Message-ID: <20230414164329.7ygncnxh2ap5mak4@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 On 2023-Apr-14, Greg Stark wrote: > On Fri, 14 Apr 2023 at 09:47, Jonathan S. Katz wrote: > > > > Let me restate [1] in a different way. > > > > Using a large enough dataset, I did qualitatively look at overall usage > > of both "vacuum_defer_cleanup_age" and compared to > > "hot_standby_feedback", given you can use both to accomplish similar > > outcomes. > > I assume people would use hot_standby_feedback if they have streaming > replication. Yes, either that or a replication slot. vacuum_defer_cleanup_age was added in commit efc16ea52067 (2009-12-19), for Postgres 9.0. hot_standby_feedback is a bit newer (bca8b7f16a3e, 2011-02-16), and replication slots are newer still (858ec11858a9, 2014-01-31). > The main use cases for vacuum_defer_cleanup_age would be if you're > replaying WAL files. That may sound archaic but there are plenty of > circumstances where your standby may not have network access to your > primary at all or not want to be replaying continuously. True, those cases exist. However, it sounds to me like in those cases vacuum_defer_cleanup_age doesn't really help you either; you'd just want to pause WAL replay depending on your queries or whatever. After all, you'd have to feed the WAL files "manually" to replay, so you're in control anyway without having to touch the primary. I find it very hard to believe that people are doing stuff with vacuum_defer_cleanup_age that cannot be done with either of the other newer mechanisms, which have also seen much wider usage and so bugs fixed, etc. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Oh, great altar of passive entertainment, bestow upon me thy discordant images at such speed as to render linear thought impossible" (Calvin a la TV)