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 1hcZE9-0007lz-QU for pgsql-committers@arkaria.postgresql.org; Sun, 16 Jun 2019 17:46:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hcZE8-0001i4-Mm for pgsql-committers@arkaria.postgresql.org; Sun, 16 Jun 2019 17:46:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hcZE8-0001hx-Ca for pgsql-committers@lists.postgresql.org; Sun, 16 Jun 2019 17:46:00 +0000 Received: from courriel.mines-paristech.fr ([77.158.173.149] helo=antispam-1.ensmp.fr) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hcZE1-0008Hv-Fi for pgsql-committers@lists.postgresql.org; Sun, 16 Jun 2019 17:45:59 +0000 Received: from smtp-4.mines-paristech.fr (smtp-4.ensmp.fr [77.158.173.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by antispam-1.ensmp.fr (antispam.mines-paristech.fr) with ESMTPS id 4D3EF55F8B; Sun, 16 Jun 2019 19:45:50 +0200 (CEST) Received: from lancre (131.162.124.78.rev.sfr.net [78.124.162.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-4.mines-paristech.fr (Postfix) with ESMTPSA id 31DB12C005F; Sun, 16 Jun 2019 19:45:50 +0200 (CEST) Date: Sun, 16 Jun 2019 19:45:45 +0200 (CEST) From: Fabien COELHO X-X-Sender: fabien@lancre To: Tom Lane cc: Tomas Vondra , Dean Rasheed , Tomas Vondra , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Rework the pg_statistic_ext catalog In-Reply-To: <4352.1560698164@sss.pgh.pa.us> Message-ID: References: <8833.1560647898@sss.pgh.pa.us> <20156.1560650744@sss.pgh.pa.us> <20190616085651.d2hxuiqlojewed5j@development> <20190616100328.shl2hhuy2pup6ges@development> <20190616112021.2mncnuj26sbsbnzx@development> <14081.1560693790@sss.pgh.pa.us> <4352.1560698164@sss.pgh.pa.us> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-CLAMAV-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrudeihedguddvtdcutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffujgfkfhgfgggtsehttdertddtredvnecuhfhrohhmpefhrggsihgvnhcuvefqgffnjffquceotghovghlhhhosegtrhhirdgvnhhsmhhprdhfrheqnecukfhppeejkedruddvgedrudeivddrudefudenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello Tom, >> I see that Coelho's two bleeding-edge-clang animals are reporting that >> failure too. Normally I'd just ignore those two; And you'd be right. >> they break pretty regularly. Maybe you're using an >> almost-bleeding-edge clang? > > Oh --- I managed to reproduce that failure locally on RHEL6 (nothing > bleeding-edge anywhere), but it went away after make-clean-and-rebuild. > I'm suspicious that the underlying cause was failure to recompile > something that knows the value of CATALOG_VERSION_NO. Hmmm. My animals compile out of the source tree, not sure how this could happen. > This theory is insufficient to explain why Coelho's animals failed, > though. Maybe it would, if you also posit a ccache screwup? But it's > not obvious from their configurations that they're using ccache at all. Indeed, no ccache. The compilers change often (well, once a week), I do not want anything kept across compiler versions. The animals are really testing the compilers as much as they are testing postgres. However, there is an autoconf cache, but I do not see why it would have such an effect. So no clue. -- Fabien.