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 1nwRnf-00068R-BU for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Jun 2022 17:06:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nwRnd-00082Q-Dd for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Jun 2022 17:06:25 +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 1nwRnd-00080n-1Z for pgsql-hackers@lists.postgresql.org; Wed, 01 Jun 2022 17:06:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nwRna-0003rv-Qe for pgsql-hackers@postgresql.org; Wed, 01 Jun 2022 17:06:24 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 251H6LnA626380; Wed, 1 Jun 2022 13:06:21 -0400 From: Tom Lane To: Zhihong Yu cc: Nathan Bossart , PostgreSQL-development Subject: Re: silence compiler warning in brin.c In-reply-to: References: <20220601163537.GA2331988@nathanxps13> Comments: In-reply-to Zhihong Yu message dated "Wed, 01 Jun 2022 09:46:52 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <626378.1654103181.1@sss.pgh.pa.us> Date: Wed, 01 Jun 2022 13:06:21 -0400 Message-ID: <626379.1654103181@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Zhihong Yu writes: > On Wed, Jun 1, 2022 at 9:35 AM Nathan Bossart > wrote: >> I'm seeing a compiler warning in brin.c with an older version of gcc. >> Specifically, it seems worried that a variable might not be initialized. >> AFAICT there is no real risk, so I've attached a small patch to silence the >> warning. Yeah, I noticed the other day that a couple of older buildfarm members (curculio, gaur) are grousing about this too. We don't really have a hard-n-fast rule about how old a compiler needs to be before we stop worrying about its notions about uninitialized variables, but these are kind of old. Still, since this is the only such warning from these animals, I'm inclined to silence it. > It seems the variable can be initialized to the value of GUCNestLevel since > later in the func: > /* Roll back any GUC changes executed by index functions */ > AtEOXact_GUC(false, save_nestlevel); That seems pretty inappropriate. If, thanks to some future thinko, control were able to reach the AtEOXact_GUC call despite not having called NewGUCNestLevel, we'd want that to fail. It looks like AtEOXact_GUC asserts nestLevel > 0, so that either 0 or -1 would do as an "invalid" value; I'd lean a bit to using 0. regards, tom lane