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 1llKio-0001SL-AM for pgsql-hackers@arkaria.postgresql.org; Tue, 25 May 2021 00:14:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1llKin-0000QB-9u for pgsql-hackers@arkaria.postgresql.org; Tue, 25 May 2021 00:14:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1llKim-0000Q3-VW for pgsql-hackers@lists.postgresql.org; Tue, 25 May 2021 00:14:57 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1llKil-00076Q-0H for pgsql-hackers@postgresql.org; Tue, 25 May 2021 00:14:56 +0000 Received: by mail-ed1-x52d.google.com with SMTP id df21so34014825edb.3 for ; Mon, 24 May 2021 17:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cye7FbHzi1462cRXTc3fcEi5gv1Bb4W/MPu5IczdyJc=; b=EBTpBNFtQd62zmI7ANTacEw1oy6HPxlP6wP/lN6XRDBW3uCb4OQBC/0JgiVoQ9MHr6 yuyG0p7jxTxNCM0mgev/11D2b2cFpjjqEVZPo5C9Pt7iSfcDO4UNVOZ7uhefAig2jLOH bzzzTuw/ZPei71UnQeeHnOjbCmXaUbQd/CAkujr8MbAfxh6U48iCuiOjn89fGyQJI4v1 VeWA2RzzjDxdlfw9IDOxfD+Uqk/8K5D2FZRJiDBzm1UPI1HHMMuTkaIrGBjKENQbS2Ms Htod0TcsrOjfkcFpj5LjQd3Ap40EV6I8c61k2H4k2zVKLDa8+xCI7QD+0tbPXyGfUHW+ TtDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cye7FbHzi1462cRXTc3fcEi5gv1Bb4W/MPu5IczdyJc=; b=SsHoUzfVR4Q3d7UEtDiZ18V+PDJ5Y19H6cdIyYU8z8LzANXvhMcGk686WTMHWgaXt8 OJun0u8YWZnzf+NoKzKLYghOwESGqpTUx4qKDH3PsIr8lj8QvajWdmMhrDtS8xyi/C79 pgdlwmbFTwa5TSZnkUkMYdkMhxFe2RK5tSo/quQDFhzAe9AxjvAQ0JuJ3vhJBf0nRDnX p8QQ9v+nXn7Wk+O5PsnPylmP42yFYWkaojp/qozXMGVAdHcUQcNFvfa/ClvpMxHCHNOc xgCX2TY6thggKX9s5uyWXIQkPz698UUUV8TIsn0ZZXnWpYyVuoSMu+Abkt2xugqDxTz/ JhyA== X-Gm-Message-State: AOAM533Ck3D3pwpXzwELR/bpqrzCGMOhliuo0i0reIAArDYlVLT5XKT5 7MAZbANqp4R4TAgsXS8F9i4RWGV/AqWbhoXqcuoAvA== X-Google-Smtp-Source: ABdhPJw+MT35JSigOItSj3JJSyLs0fooNZm9BrPw1r/lajM2Fa0EmLwws+ckoH8t1ZUjzrrnlE9+yW/TO4CmLHKOnIk= X-Received: by 2002:aa7:dc49:: with SMTP id g9mr28163724edu.160.1621901692782; Mon, 24 May 2021 17:14:52 -0700 (PDT) MIME-Version: 1.0 References: <20210423204306.5osfpkt2ggaedyvy@alap3.anarazel.de> <20210424002921.pb3t7h6frupdqnkp@alap3.anarazel.de> In-Reply-To: From: Peter Geoghegan Date: Mon, 24 May 2021 17:14:36 -0700 Message-ID: Subject: Re: Testing autovacuum wraparound (including failsafe) To: Masahiko Sawada Cc: Andres Freund , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, May 18, 2021 at 12:10 AM Masahiko Sawada wrote: > Since there is the condition "vacrel->num_index_scans == 0" we could > enter the failsafe mode even if the table is less than 4GB, if we > enter lazy_check_wraparound_failsafe() after executing more than one > index scan. Whereas a vacuum on the table that is less than 4GB and > has no index never enters the failsafe mode. I think we can remove > this condition since I don't see the reason why we don't allow to > enter the failsafe mode only when the first-time index scan in the > case of such tables. What do you think? I'm convinced -- this does seem like premature optimization now. I pushed a version of the patch that removes that code just now. Thanks -- Peter Geoghegan