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
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
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
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
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 |
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.
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
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
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
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
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
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().
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
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 backpatched
16 matches
Mail list logo
