Re: incorrect xlog.c coverage report

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: incorrect xlog.c coverage report
Date: 2018-11-21 07:18:08
Message-ID: CAD21AoAk3526uVb+9Js_XaMYeMF34YiG+SefRY9-Npq+foPsPQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 21, 2018 at 12:50 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>
> I noticed some strangeness in the test coverage reporting. For example,
> in
> https://coverage.postgresql.org/src/backend/access/transam/xlog.c.gcov.html
> in the function readRecoveryCommandFile(), most of the branches parsing
> the individual recovery options (recovery_target_xid,
> recovery_target_time, etc.) are shown as never hit, even though there
> are explicit tests for this in
> src/test/recovery/t/003_recovery_targets.pl. I tried this locally and
> also with -O0 just in case, but I get the same results. Any ideas?
>

I've looked into this issue and this happens on my environment (CentOS
6.9 and gcob 4.4.7) as well. ISTM the cause would related to the
immediate shutdown mode we're using in test_recovery_standby.
Interestingly in my environment with the attached one-line patch the
coverage reports the branches parsing the individual recovery options
correctly.

If my investigation is correct, all tests where use an immediate
shutdown might not counted by gcov.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment Content-Type Size
gcov.patch application/octet-stream 441 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-11-21 07:24:50 Re: [HACKERS] proposal: schema variables
Previous Message Michael Paquier 2018-11-21 07:09:41 Re: A WalSnd issue related to state WALSNDSTATE_STOPPING