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 1hFhMN-0000YM-9c for pgsql-hackers@arkaria.postgresql.org; Sun, 14 Apr 2019 15:47:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hFhMJ-0005Ib-KW for pgsql-hackers@arkaria.postgresql.org; Sun, 14 Apr 2019 15:47:55 +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 1hFhMJ-0005IU-CC for pgsql-hackers@lists.postgresql.org; Sun, 14 Apr 2019 15:47:55 +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 1hFhMF-000852-DI for pgsql-hackers@postgresql.org; Sun, 14 Apr 2019 15:47:54 +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 x3EFlek5015752; Sun, 14 Apr 2019 11:47:40 -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> Comments: In-reply-to Robert Haas message dated "Thu, 04 Apr 2019 15:05:55 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15750.1555256860.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Apr 2019 11:47:40 -0400 Message-ID: <15751.1555256860@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Wed, Apr 3, 2019 at 10:32 PM Masahiko Sawada = wrote: >> Attached the updated version patch. > Committed with a little bit of documentation tweaking. topminnow just failed an assertion from this patch: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dtopminnow&dt=3D2= 019-04-14%2011%3A01%3A48 The symptoms are: TRAP: FailedAssertion("!((params->index_cleanup =3D=3D VACOPT_TERNARY_ENAB= LED && nleft_dead_tuples =3D=3D 0 && nleft_dead_itemids =3D=3D 0) || param= s->index_cleanup =3D=3D VACOPT_TERNARY_DISABLED)", File: "/home/nm/farm/mi= psel_deb8_gcc_32/HEAD/pgsql.build/../pgsql/src/backend/access/heap/vacuuml= azy.c", Line: 1404) ... 2019-04-14 14:49:16.328 CEST [15282:5] LOG: server process (PID 18985) wa= s terminated by signal 6: Aborted 2019-04-14 14:49:16.328 CEST [15282:6] DETAIL: Failed process was running= : autovacuum: VACUUM ANALYZE pg_catalog.pg_depend Just looking at the logic around index_cleanup, I rather think that that assertion is flat out wrong: + /* No dead tuples should be left if index cleanup is enabled */ + Assert((params->index_cleanup =3D=3D VACOPT_TERNARY_ENABLED && + nleft_dead_tuples =3D=3D 0 && nleft_dead_itemids =3D=3D 0) || + params->index_cleanup =3D=3D VACOPT_TERNARY_DISABLED); Either it's wrong, or this is: + /* + * Since this dead tuple will not be vacuumed and + * ignored when index cleanup is disabled we coun= t + * count it for reporting. + */ + if (params->index_cleanup =3D=3D VACOPT_TERNARY_E= NABLED) + nleft_dead_tuples++; The poor quality of that comment suggests that maybe the code is just as confused. (I also think that that "ternary option" stuff is unreadably overdesigned notation, which possibly contributed to getting this wrong. If even the author can't keep it straight, it's unreadable.) regards, tom lane