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 1pF3LQ-0002mP-DH for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Jan 2023 01:22:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pF3LO-0004nt-Ls for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Jan 2023 01:22: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 1pF3LO-0004nk-D1 for pgsql-hackers@lists.postgresql.org; Tue, 10 Jan 2023 01:22:26 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pF3LI-0008W2-4h for pgsql-hackers@lists.postgresql.org; Tue, 10 Jan 2023 01:22:26 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id CAF1E3200991; Mon, 9 Jan 2023 20:22:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 09 Jan 2023 20:22:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1673313737; x=1673400137; bh=0NxwguTfa7 16+UcQd97yEgSxIG7kXxMHa3o4BcKVWpI=; b=nHKSy3qa62PdT123HgoIZpeNeA JJGmOrbK+QQKXbs+18hVpas6vaVHGKi7SlZ+HpHa4h2JiqxxzztMEsZW9PX2GKsG GtLY6I0jfDZPQOZKRQmsayzOBDD9IXNDDa/qtrPtafNdLi+AjWDslHPcxMBd0p3x CRF9HfIKCh/QqTkr0PWXZjSv1cvTzwQkFKXnHOdAe3dycBy3WfZOy0q06DvlU00C dncgSBuR/+59o7lcOoqLrQpEcW53fUD6BTmcNxSR33w5uJr7WeXhj/xwAYPHxIgq 6vJLBcI/suIkvWUASQ1NK8Q6phEVDSwcOZj7bVuL9kOJopwIqDp+YFxchXSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references: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=1673313737; x=1673400137; bh=0NxwguTfa716+UcQd97yEgSxIG7k XxMHa3o4BcKVWpI=; b=DXqjnHv5+19VxvwSfNPyn+af/bsHPfQg7+sLhYz4Mrh1 ZGNw/6uhGu54qb9B4P7U7KLoKZbG5ssg45FnooEBkmpFpwpPAFSAy/ZXk4ukId/x FXn3b6zgaCKSvv4CmykeHgzLWUVHe5t2uZsmcNgiO3Pj14fZws25agVQxrMlzDWl m6VZ69r6iNCQvIghSPxMQ3YRLHlx0BCN8YhJXGeckxt5t2Ku1710mzajbW34Q84A n/8MtFq3As6pnsXTtNmuLi++VnEVWU7HGrjQR2PZalE1h/y+B/fT0CmJvj+iB+LD YlN5i1fHkB5REg0pNa+QyhDWVqJnaWJk2DVNAh6R4Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrkeejgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtffrrg htthgvrhhnpedvffefvefhteevffegieetfefhtddvffejvefhueetgeeludehteevudei tedtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Jan 2023 20:22:16 -0500 (EST) Date: Mon, 9 Jan 2023 17:22:15 -0800 From: Andres Freund To: Peter Geoghegan Cc: Jeff Davis , PostgreSQL Hackers Subject: Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation Message-ID: <20230110012215.fgmzfx6oabtj3pja@awork3.anarazel.de> References: <5308f8fdd85fea4cd3c3e5cab2e64e164c46c6d9.camel@j-davis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2023-01-08 17:49:20 -0800, Peter Geoghegan wrote: > Teach autovacuum.c to launch "table age" autovacuums at the same point > that it previously triggered antiwraparound autovacuums. Antiwraparound > autovacuums are retained, but are only used as a true option of last > resort, when regular autovacuum has presumably tried and failed to > advance relfrozenxid (likely because the auto-cancel behavior kept > cancelling regular autovacuums triggered based on table age). I've also seen the inverse, with recent versions of postgres: Autovacuum can only ever make progress if it's an anti-wraparound vacuum, because it'll always get cancelled otherwise. I'm worried that substantially increasing the time until an anti-wraparound autovacuum happens will lead to more users running into out-of-xid shutdowns. I don't think it's safe to just increase the time at which anti-wrap vacuums happen to a hardcoded 1 billion. I'm also doubtful that it's ok to just make all autovacuums on relations with an age > 1 billion anti-wraparound ones. For people that use a large autovacuum_freeze_max_age that will be a rude awakening. I am all in favor for adding logic to trigger autovacuum based on the table age, without needing to reach autovacuum_freeze_max_age. It never made sense to me that we get to the "emergency mode" in entirely normal operation. But I'm not in favor of just entirely reinterpreting existing GUCs and adding important thresholds as hardcoded numbers. Greetings, Andres Freund