Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGCZd-0002gU-Ta for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 01:07:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hGCZc-000751-B0 for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 01:07:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGCZc-00074u-28 for pgsql-hackers@lists.postgresql.org; Tue, 16 Apr 2019 01:07:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGCZZ-0005yH-Ik for pgsql-hackers@postgresql.org; Tue, 16 Apr 2019 01:07:43 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x3G17G3F028992; Mon, 15 Apr 2019 21:07:16 -0400 From: Tom Lane To: Robert Haas cc: Masahiko Sawada , Kyotaro HORIGUCHI , "Bossart, Nathan" , Alvaro Herrera , PostgreSQL-development Subject: Re: New vacuum option to do only freezing In-reply-to: References: <20190403.131702.71087088.horiguchi.kyotaro@lab.ntt.co.jp> <20190404.091743.76975665.horiguchi.kyotaro@lab.ntt.co.jp> <15751.1555256860@sss.pgh.pa.us> <16814.1555348381@sss.pgh.pa.us> <23885.1555357618@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Mon, 15 Apr 2019 21:03:03 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28990.1555376836.1@sss.pgh.pa.us> Date: Mon, 15 Apr 2019 21:07:16 -0400 Message-ID: <28991.1555376836@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Mon, Apr 15, 2019 at 3:47 PM Tom Lane wrote: >> No. I'm thinking there should be exactly one test of index_cleanup >> in this logic, and what it would be is along the lines of ... > I'm not sure that's correct. If you do that, it'll end up in the > non-tupgone case, which might try to freeze a tuple that should've > been removed. Or am I confused? If we're failing to remove it, and it's below the desired freeze horizon, then we'd darn well better freeze it instead, no? Since we know that the tuple only just became dead, I suspect that the case would be unreachable in practice. But the approach you propose risks violating the invariant that all old tuples will either be removed or frozen. regards, tom lane