Hi,
On Fri, 5 Sept 2025 at 13:39, Oreo Yang wrote:
>
> It looks very cool.
Thanks!
> So our goal over 90%?
I am not sure of that but of course the higher the better.
--
Regards,
Nazir Bilal Yavuz
Microsoft
Hi,
On Fri, 5 Sept 2025 at 22:14, Álvaro Herrera wrote:
>
> Thanks for working on this!
>
> On 2025-Sep-05, Nazir Bilal Yavuz wrote:
>
> > 1- One Github Actions run takes ~50 minutes for now and since this
> > runs daily it is ~1500 minutes in total for a month. If you include
> > manual triggers
Thanks for working on this!
On 2025-Sep-05, Nazir Bilal Yavuz wrote:
> 1- One Github Actions run takes ~50 minutes for now and since this
> runs daily it is ~1500 minutes in total for a month. If you include
> manual triggers and failures, it is more than 1500 minutes. Github
> allows 2000 minute
Hi,
On Fri, 5 Sept 2025 at 18:14, Jacob Champion
wrote:
>
> On Fri, Sep 5, 2025 at 12:09 AM Nazir Bilal Yavuz wrote:
> > I have been working on generating differential code coverage for
> > Postgres and was able to do so with this script [1]. The script checks
> >
Hi,
On Fri, 5 Sept 2025 at 18:14, Andres Freund wrote:
>
> On 2025-09-05 10:09:27 +0300, Nazir Bilal Yavuz wrote:
> > I have been working on generating differential code coverage for
> > Postgres and was able to do so with this script [1]. The script checks
> > out HEA
On Fri, Sep 5, 2025 at 12:09 AM Nazir Bilal Yavuz wrote:
> I have been working on generating differential code coverage for
> Postgres and was able to do so with this script [1]. The script checks
> out HEAD and the latest release branch (currently REL_18_STABLE), then
> generates a
Hi,
On 2025-09-05 10:09:27 +0300, Nazir Bilal Yavuz wrote:
> I have been working on generating differential code coverage for
> Postgres and was able to do so with this script [1]. The script checks
> out HEAD and the latest release branch (currently REL_18_STABLE), then
>
It looks very cool.
So our goal over 90%?
Thanks,
OreoYang
发件人: Nazir Bilal Yavuz
已发送: 2025 年 9 月 5 日 星期五 15:09
收件人: PostgreSQL Hackers
抄送: Andres Freund ; Álvaro Herrera
主题: Differential Code Coverage report for Postgres
Hi,
I have been working on generating
Hi,
I have been working on generating differential code coverage for
Postgres and was able to do so with this script [1]. The script checks
out HEAD and the latest release branch (currently REL_18_STABLE), then
generates a differential coverage report.
I also set up a GitHub Action so the report
te.html#B0
> seem to have lost files? Clicking around I get a bunch of 404s.
Andres and I have been working on generating automated differential
code coverage reports for Postgres. The code is available in the
following repository: [1].
Branches are:
main -> uses the Meson build system.
m
Hi
I updated our coverage building server from bullseye to bookworm today.
That got us from lcov 1.14 to ... 1.16. Disappointing! But lcov 2.0,
with support for differential report, is just around the corner, so I
thought I could spend some time figuring out how to make it generate
those reports
On Tue, 2024-04-16 at 11:58 -0700, Andres Freund wrote:
>
> Hm, that seems annoying, even for update-unicode :/. But I guess it
> won't be
> very common to have such failures?
Things don't change a lot between Unicode versions (and are subject to
the stability policy), but the tests are exhaustiv
On Mon, 2024-04-15 at 21:35 -0400, Tom Lane wrote:
> It's definitely not OK for the standard test suite to include
> internet access.
The update-unicode target is not run as part of the standard test
suite.
> Seems like we need to separate "download new
> source files" from "generate the derive
Hi,
On 2024-04-15 18:23:21 -0700, Jeff Davis wrote:
> On Mon, 2024-04-15 at 17:05 -0700, Andres Freund wrote:
> > Can't we test this as part of the normal testsuite?
>
> One thing that complicates things a bit is that the test compares the
> results against ICU, so a mismatch in Unicode version b
On Tue, 16 Apr 2024 at 14:29, Andres Freund wrote:
> I think total_nblocks might also not be entirely stable?
I think it is stable for this test. However, I'll let the buildfarm
make the final call on that.
The reason I want to include it is that I'd like to push the large
allocations to the ta
Hi,
On 2024-04-16 13:50:14 +1200, David Rowley wrote:
> I think primarily it's good to exercise that code just to make sure it
> does not crash. Looking at the output of the above on my machine:
Agreed.
> name | ident | parent | level | total_bytes |
> total_nblocks | free_by
On Tue, 16 Apr 2024 at 10:57, Andres Freund wrote:
> I guess was thinking more about BumpIsEmpty() and BumpStats() then the "bogus"
> cases. But BumpIsEmpty() likely is unreachable as well.
The only call to MemoryContextIsEmpty() I see is AtSubCommit_Memory()
and it's on an aset.c context type. I
Jeff Davis writes:
> On Mon, 2024-04-15 at 17:05 -0700, Andres Freund wrote:
>> I don't at all like that the tests depend on downloading new unicode
>> data. What if there was an update but I just want to test the current
>> state?
> I was mostly following the precedent for normalization. Should
On Mon, 2024-04-15 at 17:05 -0700, Andres Freund wrote:
> Can't we test this as part of the normal testsuite?
One thing that complicates things a bit is that the test compares the
results against ICU, so a mismatch in Unicode version between ICU and
Postgres can cause test failures. The test ignor
Hi,
On 2024-04-15 16:53:48 -0700, Jeff Davis wrote:
> On Sun, 2024-04-14 at 15:33 -0700, Andres Freund wrote:
> > - Coverage for some of the new unicode code is pretty poor:
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/common/unicode_category.c.gcov.html#L122
>
> Thank you
On Sun, 2024-04-14 at 15:33 -0700, Andres Freund wrote:
> - Coverage for some of the new unicode code is pretty poor:
>
> https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/common/unicode_category.c.gcov.html#L122
Thank you for looking. Those functions are tested by category_test.c
which
Hi,
On 2024-04-16 10:26:57 +1200, David Rowley wrote:
> On Mon, 15 Apr 2024 at 10:33, Andres Freund wrote:
> > - The new bump allocator has a fair amount of uncovered functionality:
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/utils/mmgr/bump.c.gcov.html#L293
>
>
On Mon, 15 Apr 2024 at 10:33, Andres Freund wrote:
> - The new bump allocator has a fair amount of uncovered functionality:
>
> https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/utils/mmgr/bump.c.gcov.html#L293
The attached adds a test to tuplesort to exercise BumpAllocLarge()
Hi,
On 2024-04-15 15:36:04 -0400, Robert Haas wrote:
> On Sun, Apr 14, 2024 at 6:33 PM Andres Freund wrote:
> > - Some of the new walsummary code could use more tests.
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/backup/walsummaryfuncs.c.gcov.html#L69
>
> So this
On Sun, Apr 14, 2024 at 6:33 PM Andres Freund wrote:
> - Some of the new walsummary code could use more tests.
>
> https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/backup/walsummaryfuncs.c.gcov.html#L69
So this is pg_wal_summary_contents() and
pg_get_wal_summarizer_state(). I
On Sun, Apr 14, 2024 at 6:33 PM Andres Freund wrote:
> - Some of the new nbtree code could use a bit more tests:
>
> https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/access/nbtree/nbtutils.c.gcov.html#L1468
I made a conscious decision to not add coverage for the function that
Hi,
To see how well we're doing testing newly introduced code, I computed the
differential code coverage between REL_16_STABLE and HEAD.
While arguably comparing HEAD to the the merge-base between REL_16_STABLE and
HEAD would be more accurate, I chose REL_16_STABLE because we've b
Hi,
On 2023-04-04 09:03:45 -0700, Andres Freund wrote:
> For quite a while I'd been wishing to see *differential* code coverage, to see
> what changed in code coverage between two major releases. Unfortunately lcov
> didn't provide that. A few months ago a PR for it has be
> On 4 Apr 2023, at 18:03, Andres Freund wrote:
> I'm planning to generate the 15->16 differential code coverage, once the
> feature freeze has been reached.
Cool!
> I think for now it'd likely be a small script that'd generate the code
> coverage across ver
29 matches
Mail list logo
