Re: Coverage (lcov) failing with inconsistent error in versions 2.x

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: "Jonathan Gonzalez V(dot)" <jonathan(dot)abdiel(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Coverage (lcov) failing with inconsistent error in versions 2.x
Date: 2026-07-01 15:22:07
Message-ID: CAOYmi+kw+LL82qjiBmwrigk85fKcBn++UtVKAEcDRRWn3ZXy=Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 1, 2026 at 7:15 AM Jonathan Gonzalez V.
<jonathan(dot)abdiel(at)gmail(dot)com> wrote:
> Right now with the version that I have for Ubuntu 26.04 (lcov 2.0) I
> don't have more issues than the `range` one that I'm trying to confirm
> in the other thread if it is or not an issue.
>
> Well, if we're not tracking down all the errors, at least we should try
> to keep some fix related to the code that make sense, and for other
> errors, probably we should document which version of lcov we support and
> the proper .lcovrc file with the errors to ignore so no one have the
> same problem in the future?

See also [1].

I don't have a super strong opinion on documentation. Personally, I'd
be unlikely to commit a patch that tells everyone to start ignoring
the same errors across the board. lcov 2 is just in a weird spot right
now. And you don't have to use lcov/genhtml, and clang/llvm-cov have
their own thing going on, and different compiler versions are clearly
interacting with lcov in different ways...

We could rewrite https://wiki.postgresql.org/wiki/CodeCoverage, maybe.

(As an aside: I want to be careful in how I speak about lcov 2.x. I'm
not an expert in that system, and it's entirely possible that all of
the errors causing it to bail out by default are in fact legitimate
problems in the underlying coverage data that is emitted by a
compiler, rather than bugs in lcov. But I do believe that the current
state of lcov makes it pretty much unfit for purpose with today's
widely-used toolchains and codebases. I'm pretty disappointed in how
v2 is behaving.)

Thanks,
--Jacob

[1] https://postgr.es/m/flat/CAJ7c6TN%2BMCh99EZ8YGhXZAdnqvNQYir6E34B_mmcB5KsxCB00A%40mail.gmail.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2026-07-01 15:24:37 Re: Allow progress tracking of sub-commands
Previous Message Anthonin Bonnefoy 2026-07-01 15:21:18 Re: Improve row estimation with multi-column unique indexes