Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rAtTl-008cGg-RT for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Dec 2023 15:06:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rAtTk-00AJqU-92 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Dec 2023 15:06:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rAtTj-00AJqM-Vp for pgsql-hackers@lists.postgresql.org; Wed, 06 Dec 2023 15:06:23 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rAtTh-00966s-KD for pgsql-hackers@lists.postgresql.org; Wed, 06 Dec 2023 15:06:22 +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 3B6F6HPg1100557; Wed, 6 Dec 2023 10:06:17 -0500 From: Tom Lane To: Peter Eisentraut cc: Bharath Rupireddy , PostgreSQL Hackers Subject: Re: Is WAL_DEBUG related code still relevant today? In-reply-to: <5a2e43da-0425-4fc1-9b13-19fd33123950@eisentraut.org> References: <5a2e43da-0425-4fc1-9b13-19fd33123950@eisentraut.org> Comments: In-reply-to Peter Eisentraut message dated "Wed, 06 Dec 2023 12:27:17 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1100555.1701875177.1@sss.pgh.pa.us> Date: Wed, 06 Dec 2023 10:06:17 -0500 Message-ID: <1100556.1701875177@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > This kind of thing could be mostly avoided if we didn't hide all the > WAL_DEBUG behind #ifdefs. For example, in the attached patch, I instead > changed it so that > if (XLOG_DEBUG) > resolves to > if (false) > in the normal case. That way, we don't need to wrap that in #ifdef > WAL_DEBUG, and the compiler can see the disabled code and make sure it > continues to build. Hmm, maybe, but I'm not sure this would be an unalloyed good. The main concern I have is compilers and static analyzers starting to bleat about unreachable code (warnings like "variable set but never used", or the like, seem plausible). The dead code would also decrease our code coverage statistics, not that those are wonderful now. regards, tom lane