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 1o5vTp-0004hc-5s for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jun 2022 20:37:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o5vTn-0000vx-0O for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jun 2022 20:37:07 +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 1o5vTm-0000vn-JV for pgsql-hackers@lists.postgresql.org; Mon, 27 Jun 2022 20:37:06 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o5vTk-0005zv-5A for pgsql-hackers@lists.postgresql.org; Mon, 27 Jun 2022 20:37:05 +0000 Received: by mail-ej1-x635.google.com with SMTP id q6so21480523eji.13 for ; Mon, 27 Jun 2022 13:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nzjtt3pxHLnzZgLTzs4Ka2HYqd99alS3oPkedY+fhAk=; b=LUbdYAgAvkcPYVj9voSsSFGQzU3BEnUR76zA7xxp1owz5W9+KeW+sox/WyJ+zqKz8L P4gPDgEmhGuXehJChXozLehxf4rr3JSWzeTdc9IFvDx78G8C6B0cda/FSfAmq70dwXSQ 4kfouMO6wrYqR6Wg1WGARq+D6X2ITj6o7bIJQG8eQSH1/8GwGctDpzhMF9tCDJKvvrf4 b+NYshFy9NBYzLNUmwTPpBSDwzrJ+P+HDdUyxVj05wNS9hPo491/p7bOoXQDiXEycZhr BIoEolKz5sUa1zc29HWEtcGRkPbusTpenMWGBfsd2swhoHFAUsDVWTdF1sIxTts8G7qQ /7XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nzjtt3pxHLnzZgLTzs4Ka2HYqd99alS3oPkedY+fhAk=; b=W8YsQQ/zNxceg2W/deXhP1zwOavdPhG8/iinrymAs+yorU9xUk97u1Byq6oKvrxogn X94xbwwk/fqGBSVOqKCrjzflzO8WJ3CM1+9PXfiK/Pgp29ep+3SCQZBlNfyN+fw9tBXX qJMco+4CJEPNGM7Sh1O5xI4q86+VKpsnaVBm+dj+PcxkJnU9TVQ+SnyRD1XOO5yB/C7T 80hQ2jF4RvjQp6rSCLBK1XIBeZ0+/LeyfQintqHbgZGcalzeneSSxxtbUu//YKe0+O69 0HNI22OD249140WxbDcHDHR3wdeLg5Lo1Gg9pj4iRycW1nNJiiQRP0uPyfZCUEdMBNfI il1g== X-Gm-Message-State: AJIora8XgfVV6H0ZyK4JN2PUegTs5OKfGpiUkeMk+zIqZFMbEGQybxSw 94nhlv0i6eZIzD2Bg0w8k4OLJAu1my2Dod/zqbhkyg== X-Google-Smtp-Source: AGRyM1uwgdaHYRgVKBswM+kW10U34vwZR2T1WXZptxnPO5kXqClZJ1JF8t6LUm4ugKYiULYnjFyUCoHpsQtQN6n8KqE= X-Received: by 2002:a17:906:9ac5:b0:726:2994:6d91 with SMTP id ah5-20020a1709069ac500b0072629946d91mr14960068ejc.74.1656362222993; Mon, 27 Jun 2022 13:37:02 -0700 (PDT) MIME-Version: 1.0 References: <20211210015616.o242b4xchhpglfcy@alap3.anarazel.de> <20220627193609.GB19662@telsasoft.com> In-Reply-To: <20220627193609.GB19662@telsasoft.com> From: Peter Geoghegan Date: Mon, 27 Jun 2022 13:36:36 -0700 Message-ID: Subject: Re: do only critical work during single-user vacuum? To: Justin Pryzby Cc: Robert Haas , Andres Freund , John Naylor , PostgreSQL Hackers , Hannu Krosing Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Jun 27, 2022 at 12:36 PM Justin Pryzby wrote: > By chance, I came across this prior thread which advocated the same thing in a > initially (rather than indirectly as in this year's thread). Revisiting this topic reminded me that PostgreSQL 14 (the first version that had the wraparound failsafe mechanism controlled by vacuum_failsafe_age) has been a stable release for 9 months now. As of today I am still not aware of even one user that ran into the failsafe mechanism in production. It might well have happened by now, of course, but I am not aware of any specific case. Perhaps this will change soon enough -- maybe somebody else will read this and enlighten me. To me the fact that the failsafe seems to seldom kick-in in practice suggests something about workload characteristics in general: that it isn't all that common for users to try to get away with putting off freezing until a table attains an age that is significantly above 1 billion XIDs. When people talk about things like 64-bit XIDs, I tend to wonder: if 2 billion XIDs wasn't enough, why should 4 billion or 8 billion be enough? *Maybe* the system can do better by getting even further into debt than it can today, but you can't expect to avoid freezing altogether (without significant work elsewhere). My general sense is that freezing isn't a particularly good thing to try to do lazily -- even if we ignore the risk of an eventual wraparound failure. -- Peter Geoghegan