Re: Question for coverage report - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: Question for coverage report
Date
Msg-id 202510171743.yihu2etsyzek@alvherre.pgsql
Whole thread Raw
In response to Re: Question for coverage report  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
On 2025-Oct-17, Jacob Champion wrote:

> On Fri, Oct 17, 2025 at 3:55 AM Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> > Oh, I didn't notice. Yeah it was also strange. Is there a
> > possibility that complier optimization did prefetch and it was also
> > counted?
> 
> FWIW, I'm used to having to set -O0 for the best coverage behavior.
> -Og _usually_ works fine, but it occasionally results in nonsensical
> reports for me.

Hmm, these reports are supposed to have been generated with -O0.  This
is the configure line:

./configure --cache-file=/home/coverage/pgsrc/configure.cache --enable-depend --enable-coverage --enable-tap-tests
--enable-nls--with-python --with-perl --with-tcl --with-openssl --with-libxml --with-ldap --with-pam --with-llvm
--with-lz4--enable-injection-points CFLAGS=-O0 'CPPFLAGS=-DCOPY_PARSE_PLAN_TREES -DWRITE_READ_PARSE_PLAN_TREES
-DRAW_EXPRESSION_COVERAGE_TEST'LLVM_CONFIG=/usr/bin/llvm-config-19 CLANG=clang-19 >> $LOG 2>&1
 

Is this somehow not effective?

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"La gente vulgar sólo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: Daniele Varrazzo
Date:
Subject: Re: Getting the SQLSTATE after a failed connection