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

От:

"Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>

Дата:

1 июля в 17:15:01

Hi!

Jacob Champion  writes:
> Thanks for the patch!

Thanks for the quick answer!

> I'm not sure we should get on the treadmill of catering to lcov, when
> I look at the huge number of errors its 2.x line now throws for
> widely-used compilers and coding styles. (Right now my ignore_errors
> setting is up to six categories, I think. Which is unfortunate, but
> its signal-to-noise ratio is just not good right now. Just yesterday I
> had to patch out an error in 2.4 that was preventing me from running
> genhtml.)
>
> --Jacob

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?

I don't think anyone will want to add a .lcovrc file to the repository,
but probably a sample file in the documentation will work?

Thanks!
--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com

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

От:

"Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>

Дата:

14 июля в 14:06:17

Hello!

Álvaro Herrera  writes:

> On 2026-Jul-06, Jacob Champion wrote:
>
>> On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera  wrote:
>> > I added -j0 to both so that they run parallel processes, which should be
>> > a few second faster.
>> 
>> As a heads up, I found that adding parallelism on my local machine ran
>> it out of memory pretty quickly, with lcov 2.4. YMMV.
>
> Strange!
>
> Anyway I noticed that "-j0" doesn't work -- apparently it has to be "-j 0".
> I'll see how bad the memory usage gets on the next report, and turn that
> off (or set it lower?) if things are too tight.

I ran into the same issues and I took a different direction, since lcov
wasn't working I started to look for other solutions, turns out that
meson comes with a fallback if lcov is not installed called gcovr, and
works really well, at least for my requirements (not running in the full
stack), without any configuration I have a coverage report, enough at
least.

Has anyone tried gcovr before? I'd be interested to know whether there
are any drawbacks to using it.

Going back to lcov, according to an issue [0], it looks like users are
expected to use the "TOT" version, which makes no sense to me. I tested
the latest lcov release from last week, and I'm still experiencing the
same issues that started this thread.

In conclusion, I'll stick with gcovr for now rather than maintaining an
lcov configuration with many exceptions.

[0] https://github.com/linux-test-project/lcov/issues/473#issuecomment-4492099808

Regards

--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com

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

От:

Álvaro Herrera <alvherre@kurilemu.de>

Дата:

3 июля в 23:17:31

On 2026-Jul-01, Jacob Champion wrote:

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

We could rewrite it, yes, but lower effort for me today was to _reread_
it, and in doing so I realized that we disabled branch reporting seven
years ago while we waited for a new GCC version; that fixed GCC version
being now ancient history, I have reenabled branch coverage.

One totally not funny thing is that with that enabled, lcov fails in
even more interesting ways; now you need to give "inconsistent,mismatch"
in LCOVFLAGS.  So the whole thing is

make coverage-html LCOVFLAGS="-q -j0 --ignore-errors usage,negative,inconsistent,mismatch" GENHTML_FLAGS="-q -j0 --legend --ignore-errors unmapped,corrupt,inconsistent,range"


I added -j0 to both so that they run parallel processes, which should be
a few second faster.  In practice it may make no difference, because the
real time eater is the xid_wraparound test, which lasts for 10 minutes
after all the other tests have completed:

# +++ tap check in src/test/modules/xid_wraparound +++
t/002_limits.pl ............ ok
t/004_notify_freeze.pl ..... ok
t/001_emergency_vacuum.pl .. ok
t/003_wraparounds.pl ....... ok
All tests successful.
Files=4, Tests=23, 415 wallclock secs ( 0.04 usr  0.00 sys +  7.31 cusr 3.81 csys = 11.16 CPU)
Result: PASS


Regards

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"

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

От:

Álvaro Herrera <alvherre@kurilemu.de>

Дата:

6 июля в 21:00:34

On 2026-Jul-06, Jacob Champion wrote:

> On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera  wrote:
> > I added -j0 to both so that they run parallel processes, which should be
> > a few second faster.
> 
> As a heads up, I found that adding parallelism on my local machine ran
> it out of memory pretty quickly, with lcov 2.4. YMMV.

Strange!

Anyway I noticed that "-j0" doesn't work -- apparently it has to be "-j 0".
I'll see how bad the memory usage gets on the next report, and turn that
off (or set it lower?) if things are too tight.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)

Re: pg_stat_get_autovacuum_scores ignores the main table's reloptions for TOAST tables

От:

Nathan Bossart <nathandbossart@gmail.com>

Дата:

28 августа в 23:13:30

Committed.

-- 
nathan

pg_stat_get_autovacuum_scores ignores the main table's reloptions for TOAST tables

От:

Masahiko Sawada <sawada.mshk@gmail.com>

Дата:

28 августа в 01:42:23

Hi all,
(CCing Nathan as the committer of 87f61f0c8280 and fad70a09ff43)

I found that pg_get_autovacuum_scores reports wrong values for TOAST
tables. In do_autovacuum(), we fall back to the main table's reloption
when the TOAST table has no reloptions of its own, and
table_recheck_autovac() does the same. However,
pg_stat_get_autovacuum_scores() only calls extract_autovac_opts() and
passes NULL when the TOAST table has none.

So the view computes the TOAST table's scores from rht eGUC defaults
whenever the user sets autovacuum_* on the main table without setting
the corresponding toast.* option. Here is a simple reproducer:

create table test (a int, b text);
alter table test alter column b set storage external;
alter table test set (autovacuum_vacuum_threshold = 1,
autovacuum_vacuum_scale_factor = 0, autovacuum_enabled = false);
insert into test select i, repeat('z',4000) from generate_series(1,200) i;
delete from test where a <= 100;
select relid::regclass, vacuum_score, do_vacuum from
pg_stat_autovacuum_scores where relid in ('test'::regclass, (select
reltoastrelid from pg_class where relname = 'test'));
          relid          | vacuum_score | do_vacuum
-------------------------+--------------+-----------
 test                    |          100 | f
 pg_toast.pg_toast_16384 |            6 | t
(2 rows)

And what the autovacuum worker computes for the same two relations is:

DEBUG: test: vac: 100 (thresh 1, score 100.00), ...
DEBUG:  pg_toast_16384: vac: 300 (thresh 1, score 300.00), ...

Which doesn't match what the view shows.

Note that this issue happens only in v19 as commit fad70a09ff43 fixed
autovacuum's handling of TOAST reloptions. While I agree that the
commit was not backpatched to v19, I think we should fix how the view
computes the toast table's reloptions.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Re: pg_stat_get_autovacuum_scores ignores the main table's reloptions for TOAST tables

От:

Masahiko Sawada <sawada.mshk@gmail.com>

Дата:

28 августа в 21:12:34

On Fri, Aug 28, 2026 at 8:16 AM Nathan Bossart  wrote:
>
> On Fri, Aug 28, 2026 at 10:02:42AM -0500, Nathan Bossart wrote:
> > Here is a patch.
>
> Sorry for the noise.  I noticed some silly mistakes in v1, so here's a v2
> with those fixed.

Thank you for making the patch quickly! The patch looks good to me. A nitpick:

+           if (found && hentry->ar_hasrelopts)
+               avopts = &hentry->ar_reloptions;

ar_hasrelopts is always true here, since entries are only created when
extract_autovac_opts() returns non-NULL, so the second conjunct is
redundant actually. Having said that, it seems safer for future
changes and keeping it for symmetry with do_autovacuum() seems fine to
me.

Do we want to have regression tests for it? FWIW no test exercises
pg_stat_get_autovacuum_scores(). The only reference in the tree is the
view definition in rules.out. That's presumably why this went
unnoticed.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

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

От:

Jacob Champion <jacob.champion@enterprisedb.com>

Дата:

1 июля в 18:22:07

On Wed, Jul 1, 2026 at 7:15 AM Jonathan Gonzalez V.
 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

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

От:

Jacob Champion <jacob.champion@enterprisedb.com>

Дата:

1 июля в 15:28:44

On Wed, Jul 1, 2026 at 5:14 AM Jonathan Gonzalez V.
 wrote:
> These failure has already been discussed here[0], but this is a
> patch on the code rather than add an exception.

Thanks for the patch!

I'm not sure we should get on the treadmill of catering to lcov, when
I look at the huge number of errors its 2.x line now throws for
widely-used compilers and coding styles. (Right now my ignore_errors
setting is up to six categories, I think. Which is unfortunate, but
its signal-to-noise ratio is just not good right now. Just yesterday I
had to patch out an error in 2.4 that was preventing me from running
genhtml.)

--Jacob