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 1la86v-0003BQ-6M for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Apr 2021 02:33:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1la86s-0005s0-LX for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Apr 2021 02:33:30 +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 1la86r-0005rt-Oz for pgsql-hackers@lists.postgresql.org; Sat, 24 Apr 2021 02:33:30 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1la86j-00040n-R0 for pgsql-hackers@postgresql.org; Sat, 24 Apr 2021 02:33:28 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 98EEF2D75; Fri, 23 Apr 2021 22:33:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 23 Apr 2021 22:33:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=5mUz+WOc23TBrgagULndC/h1cCr y8caxAoLsmCcSxUE=; b=rqILn6jdC/O+ilESyLfhxFP9f/ZaX42np2uGy8D6oPT +cFg+uL3h6EKNuoI1enQGIYFk9skDV8NmFTexVZP+PYQwLxmhm7o0hgQAseIdNg5 eMUcEPkkbazzU8zFDC5/232Y5R21ladOeJbLWEI/Ltmi42xs9jswzHg0o0VnY2li X7LV4iEYlnDa9q6JKJxTDjPaTyWKq87aFO5/1T8p1c2pLeKMnlnLYolqM9SWQv96 ULR7Zc+RnS5nBOXMAzceynBlGt+x+kfLOfaVW/QZOsCyf4uULSPP20igZH0O71Mv KEU9f6NuPp+c7bvYQpO8e3t4vvogUQq59mF9eMBS92Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5mUz+W Oc23TBrgagULndC/h1cCry8caxAoLsmCcSxUE=; b=K6XZb1BDwrmW5tgHymhFUm lNvx3Bs7V+RFUpZkbjJybdpoGMJp4fR8ENN1enbb6250xl011DAlMuxpgM63k+CD R7EO9TkOw7uSLVoEu0I0tk4r8SpY2Wxd8W5XuCXK4Ji2FeDafMK/ZGDYT7y+H00b Bt1Y3etCodoe8/NIHop6DJ5kUXthxyjnmhuuoawNguwM1FS5Ak8wOEGPicXSpslx 9+Z+No7SyPYvOxcdCZiiD1x8tz8gJJiZe1Nz1dlwPCjU1j95yY+SHdKtMF3Yjzir J5dTvX9HV5NBN470TOmH23H+zJ+sRP+RVOj55i6bctOnOmfcdQgqsa1t9j/XJi8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddufedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtffrrg htthgvrhhnpedukefhkeelueegveetheelffffjeegleeuudelfeefuedtleffueejfffh ueffudenucfkphepuddtjedrudegvddrfeefrddutdefnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprghnughrvghssegrnhgrrhgriigvlhdr uggv X-ME-Proxy: Received: from intern.anarazel.de (107-142-33-103.lightspeed.sntcca.sbcglobal.net [107.142.33.103]) by mail.messagingengine.com (Postfix) with ESMTPA id F22351080066; Fri, 23 Apr 2021 22:33:15 -0400 (EDT) Date: Fri, 23 Apr 2021 19:33:14 -0700 From: Andres Freund To: Peter Geoghegan Cc: PostgreSQL Hackers Subject: Re: Testing autovacuum wraparound (including failsafe) Message-ID: <20210424023314.iem2gxm7cuaj66au@alap3.anarazel.de> References: <20210423204306.5osfpkt2ggaedyvy@alap3.anarazel.de> <20210424002921.pb3t7h6frupdqnkp@alap3.anarazel.de> 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 2021-04-23 19:15:43 -0700, Peter Geoghegan wrote: > > The failsafe mode affects the table scan itself by disabling cost > > limiting. As far as I can see the ways it triggers for the table scan (vs > > truncation or index processing) are: > > > > 1) Before vacuuming starts, for heap phases and indexes, if already > > necessary at that point > > 2) For a table with indexes, before/after each index vacuum, if now > > necessary > > 3) On a table without indexes, every 8GB, iff there are dead tuples, if now necessary > > > > Why would we want to trigger the failsafe mode during a scan of a table > > with dead tuples and no indexes, but not on a table without dead tuples > > or with indexes but fewer than m_w_m dead tuples? That makes little > > sense to me. > > What alternative does make sense to you? Check it every so often, independent of whether there are indexes or dead tuples? Or just check it at the boundaries. I'd make it dependent on the number of pages scanned, rather than the block distance to the last check - otherwise we might end up doing it way too often when there's only a few individual pages not in the freeze map. Greetings, Andres Freund