agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedCoverage (lcov) failing with inconsistent error in versions 2.x
10+ messages / 4 participants
[nested] [flat]
* Coverage (lcov) failing with inconsistent error in versions 2.x
@ 2026-07-01 12:12 Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
0 siblings, 1 reply; 10+ messages in thread
From: Jonathan Gonzalez V. @ 2026-07-01 12:12 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
Hi all
While working on another patch I was suggested to check the coverage of
the tests, but I hit some errors while trying to build the coverage.
The first error and that it's fixed here are:
lcov: ERROR: (inconsistent) "/home/zeus/src/postgresql/src/interfaces/libpq/fe-auth-oauth.c":869: duplicate function 'use_builtin_flow' starts on line "/home/zeus/src/postgresql/src/interfaces/libpq/fe-auth-oauth.c":869 but previous definition started on 991 while capturing from /home/zeus/src/postgresql/build/src/interfaces/libpq/libpq.so.5.19.p/fe-auth-oauth.c.gcno.
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
lcov: ERROR: (inconsistent) "/home/zeus/src/postgresql/worktrees/lcov/src/include/lib/simplehash.h":450: duplicate function 'blockreftable_create' starts on line "/home/zeus/src/postgresql/worktrees/lcov/src/include/lib/simplehash.h":450 but previous definition started on 447 while capturing from /home/zeus/src/postgresql/worktrees/lcov/build/src/common/libpgcommon_srv.a.p/blkreftable.c.gcno.
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
These error are due to duplicated declaration of SH_CREATE() and
use_builtin_flow(), and will only appear in version of lcov >= 2.0
which is the version, but with version 1.16 this doesn't happens.
These failure has already been discussed here[0], but this is a
patch on the code rather than add an exception. That thread still having
some valid points related to another failure that should be discussed
there.
[0] https://www.postgresql.org/message-id/flat/CAHsn6_xCDQWe8_vVFhtFk27_xTdyVV%2BDr0yWzaooBZ6%2B-VH-5w%4...
--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com
Attachments:
[text/x-diff] v1-0001-libpq-oauth-collapse-use_builtin_flow-into-a-sing.patch (3.5K, ../../87ldbuc3ik.fsf@gmail.com/2-v1-0001-libpq-oauth-collapse-use_builtin_flow-into-a-sing.patch)
download | inline diff:
From 3f9a98a046f18588e77a9f1e53da7a3ee92c10cf Mon Sep 17 00:00:00 2001
From: "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>
Date: Wed, 1 Jul 2026 12:31:55 +0200
Subject: [PATCH v1 1/2] libpq-oauth: collapse use_builtin_flow() into a single
definition
There was three separated definition of the function making lcov v2.x fail
with an error.
---
src/interfaces/libpq/fe-auth-oauth.c | 61 +++++++++++-----------------
1 file changed, 24 insertions(+), 37 deletions(-)
diff --git a/src/interfaces/libpq/fe-auth-oauth.c b/src/interfaces/libpq/fe-auth-oauth.c
index 826f7461cb3..7a35647feb8 100644
--- a/src/interfaces/libpq/fe-auth-oauth.c
+++ b/src/interfaces/libpq/fe-auth-oauth.c
@@ -833,41 +833,42 @@ cleanup_oauth_flow(PGconn *conn)
* failure, and positive indicates success.
*/
-#if !defined(USE_LIBCURL)
+#if defined(USE_LIBCURL) && defined(USE_DYNAMIC_OAUTH)
/*
- * This configuration doesn't support the builtin flow.
+ * Use the builtin flow in the libpq-oauth plugin, which is loaded at runtime.
*/
-static int
-use_builtin_flow(PGconn *conn, fe_oauth_state *state, PGoauthBearerRequestV2 *request)
-{
- return 0;
-}
+typedef char *(*libpq_gettext_func) (const char *msgid);
-#elif defined(USE_DYNAMIC_OAUTH)
+#elif defined(USE_LIBCURL)
/*
- * Use the builtin flow in the libpq-oauth plugin, which is loaded at runtime.
+ * For static builds, we can just call pg_start_oauthbearer() directly. It's
+ * provided by libpq-oauth.a.
*/
+extern int pg_start_oauthbearer(PGconn *conn, PGoauthBearerRequestV2 *request);
-typedef char *(*libpq_gettext_func) (const char *msgid);
+#endif
-/*
- * Loads the libpq-oauth plugin via dlopen(), initializes it, and plugs its
- * callbacks into the connection's async auth handlers.
- *
- * Failure to load here results in a relatively quiet connection error, to
- * handle the use case where the build supports loading a flow but a user does
- * not want to install it. Troubleshooting of linker/loader failures can be done
- * via PGOAUTHDEBUG.
- *
- * The lifetime of *request ends shortly after this call, so it must be copied
- * to longer-lived storage.
- */
static int
use_builtin_flow(PGconn *conn, fe_oauth_state *state, PGoauthBearerRequestV2 *request)
{
+#if !defined(USE_LIBCURL)
+ return 0;
+#elif defined(USE_DYNAMIC_OAUTH)
+ /*
+ * Load the libpq-oauth plugin via dlopen(), initialize it, and plug its
+ * callbacks into the connection's async auth handlers.
+ *
+ * Failure to load here results in a relatively quiet connection error, to
+ * handle the use case where the build supports loading a flow but a user
+ * does not want to install it. Troubleshooting of linker/loader failures
+ * can be done via PGOAUTHDEBUG.
+ *
+ * The lifetime of *request ends shortly after this call, so it must be
+ * copied to longer-lived storage.
+ */
static bool initialized = false;
static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
int lockerr;
@@ -976,24 +977,10 @@ use_builtin_flow(PGconn *conn, fe_oauth_state *state, PGoauthBearerRequestV2 *re
}
return (start_flow(conn, request) == 0) ? 1 : -1;
-}
-
#else
-
-/*
- * For static builds, we can just call pg_start_oauthbearer() directly. It's
- * provided by libpq-oauth.a.
- */
-
-extern int pg_start_oauthbearer(PGconn *conn, PGoauthBearerRequestV2 *request);
-
-static int
-use_builtin_flow(PGconn *conn, fe_oauth_state *state, PGoauthBearerRequestV2 *request)
-{
return (pg_start_oauthbearer(conn, request) == 0) ? 1 : -1;
-}
-
#endif /* USE_LIBCURL */
+}
/*
--
2.53.0
[text/x-diff] v1-0002-Collapse-SH_CREATE-into-a-single-definition.patch (2.4K, ../../87ldbuc3ik.fsf@gmail.com/3-v1-0002-Collapse-SH_CREATE-into-a-single-definition.patch)
download | inline diff:
From aa10a3818d3ec7c40b13880788780738856c6dca Mon Sep 17 00:00:00 2001
From: "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>
Date: Wed, 1 Jul 2026 12:36:52 +0200
Subject: [PATCH v1 2/2] Collapse SH_CREATE() into a single definition
The function had two conditional definitions that make lcov v2.x fail.
---
src/include/lib/simplehash.h | 28 +++++++++++-----------------
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/src/include/lib/simplehash.h b/src/include/lib/simplehash.h
index 15af488abfb..cda4347e60b 100644
--- a/src/include/lib/simplehash.h
+++ b/src/include/lib/simplehash.h
@@ -138,6 +138,14 @@
#define SH_INSERT_HASH_INTERNAL SH_MAKE_NAME(insert_hash_internal)
#define SH_LOOKUP_HASH_INTERNAL SH_MAKE_NAME(lookup_hash_internal)
+#ifdef SH_RAW_ALLOCATOR
+/* <prefix>_hash <prefix>_create(uint32 nelements, void *private_data) */
+#define SH_CREATE_PARAMETERS uint32 nelements, void *private_data
+#else
+/* <prefix>_hash <prefix>_create(MemoryContext ctx, uint32 nelements, void *private_data) */
+#define SH_CREATE_PARAMETERS MemoryContext ctx, uint32 nelements, void *private_data
+#endif
+
/* generate forward declarations necessary to use the hash table */
#ifdef SH_DECLARE
@@ -186,17 +194,7 @@ typedef struct SH_ITERATOR
} SH_ITERATOR;
/* externally visible function prototypes */
-#ifdef SH_RAW_ALLOCATOR
-/* <prefix>_hash <prefix>_create(uint32 nelements, void *private_data) */
-SH_SCOPE SH_TYPE *SH_CREATE(uint32 nelements, void *private_data);
-#else
-/*
- * <prefix>_hash <prefix>_create(MemoryContext ctx, uint32 nelements,
- * void *private_data)
- */
-SH_SCOPE SH_TYPE *SH_CREATE(MemoryContext ctx, uint32 nelements,
- void *private_data);
-#endif
+SH_SCOPE SH_TYPE *SH_CREATE(SH_CREATE_PARAMETERS);
/* void <prefix>_destroy(<prefix>_hash *tb) */
SH_SCOPE void SH_DESTROY(SH_TYPE * tb);
@@ -442,13 +440,8 @@ SH_FREE(SH_TYPE * type, void *pointer)
* Memory other than for the array of elements will still be allocated from
* the passed-in context.
*/
-#ifdef SH_RAW_ALLOCATOR
SH_SCOPE SH_TYPE *
-SH_CREATE(uint32 nelements, void *private_data)
-#else
-SH_SCOPE SH_TYPE *
-SH_CREATE(MemoryContext ctx, uint32 nelements, void *private_data)
-#endif
+SH_CREATE(SH_CREATE_PARAMETERS)
{
SH_TYPE *tb;
uint64 size;
@@ -1217,6 +1210,7 @@ SH_STAT(SH_TYPE * tb)
#undef SH_GROW_MAX_MOVE
#undef SH_GROW_MIN_FILLFACTOR
#undef SH_MAX_SIZE
+#undef SH_CREATE_PARAMETERS
/* types */
#undef SH_TYPE
--
2.53.0
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
@ 2026-07-01 12:28 ` Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Jacob Champion @ 2026-07-01 12:28 UTC (permalink / raw)
To: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>; +Cc: pgsql-hackers@lists.postgresql.org
On Wed, Jul 1, 2026 at 5:14 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
@ 2026-07-01 14:15 ` Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
0 siblings, 1 reply; 10+ messages in thread
From: Jonathan Gonzalez V. @ 2026-07-01 14:15 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: pgsql-hackers@lists.postgresql.org
Hi!
Jacob Champion <jacob.champion@enterprisedb.com> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
@ 2026-07-01 15:22 ` Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 15:55 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Tom Lane <tgl@sss.pgh.pa.us>
2026-07-03 20:17 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 2 replies; 10+ messages in thread
From: Jacob Champion @ 2026-07-01 15:22 UTC (permalink / raw)
To: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>; +Cc: pgsql-hackers@lists.postgresql.org
On Wed, Jul 1, 2026 at 7:15 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
@ 2026-07-01 15:55 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 10+ messages in thread
From: Tom Lane @ 2026-07-01 15:55 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>; pgsql-hackers@lists.postgresql.org
Jacob Champion <jacob.champion@enterprisedb.com> writes:
> (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.)
Yeah. It seems like lcov 2.0 is kind of okay (it's working for me
anyway), but the later versions are more broken. I'm not excited
about changing our docs to reflect that, and definitely -1 on
changing our code. I think we just have to wait and hope they
get things sorted.
> We could rewrite https://wiki.postgresql.org/wiki/CodeCoverage, maybe.
+1, that page seems to be mostly ancient history at present.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
@ 2026-07-03 20:17 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-07-06 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
1 sibling, 1 reply; 10+ messages in thread
From: Álvaro Herrera @ 2026-07-03 20:17 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>; pgsql-hackers@lists.postgresql.org
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"
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-03 20:17 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-07-06 15:22 ` Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-06 18:00 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 10+ messages in thread
From: Jacob Champion @ 2026-07-06 15:22 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>; pgsql-hackers@lists.postgresql.org
On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera <alvherre@kurilemu.de> 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.
Thanks!
--Jacob
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-03 20:17 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
2026-07-06 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
@ 2026-07-06 18:00 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-07-14 11:06 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Álvaro Herrera @ 2026-07-06 18:00 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>; pgsql-hackers@lists.postgresql.org
On 2026-Jul-06, Jacob Champion wrote:
> On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera <alvherre@kurilemu.de> 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)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-03 20:17 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
2026-07-06 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-06 18:00 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-07-14 11:06 ` Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-08-25 15:44 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
0 siblings, 1 reply; 10+ messages in thread
From: Jonathan Gonzalez V. @ 2026-07-14 11:06 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>; pgsql-hackers@lists.postgresql.org
Hello!
Álvaro Herrera <alvherre@kurilemu.de> writes:
> On 2026-Jul-06, Jacob Champion wrote:
>
>> On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera <alvherre@kurilemu.de> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage (lcov) failing with inconsistent error in versions 2.x
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-03 20:17 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
2026-07-06 15:22 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-06 18:00 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Álvaro Herrera <alvherre@kurilemu.de>
2026-07-14 11:06 ` Re: Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
@ 2026-08-25 15:44 ` Jacob Champion <jacob.champion@enterprisedb.com>
0 siblings, 0 replies; 10+ messages in thread
From: Jacob Champion @ 2026-08-25 15:44 UTC (permalink / raw)
To: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; pgsql-hackers@lists.postgresql.org
On Tue, Jul 14, 2026 at 4:06 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
> Has anyone tried gcovr before? I'd be interested to know whether there
> are any drawbacks to using it.
I recently tried meson+gcovr and wasn't very happy with the default
merging/filtering of the source and build trees. So I just copy-pasted
the gcovr invocation that meson does and tweaked it to work
correctly... annoying, but less annoying than lcov. (I still need lcov
for differential coverage, though, as far as I can tell.)
--Jacob
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-08-25 15:44 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-01 12:12 Coverage (lcov) failing with inconsistent error in versions 2.x Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 12:28 ` Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 14:15 ` Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-07-01 15:22 ` Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-01 15:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-07-03 20:17 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-07-06 15:22 ` Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-06 18:00 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-07-14 11:06 ` Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
2026-08-25 15:44 ` Jacob Champion <jacob.champion@enterprisedb.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox