Re: [PATCH] Add tests for Bitmapset - Mailing list pgsql-hackers

From Greg Burd
Subject Re: [PATCH] Add tests for Bitmapset
Date
Msg-id 0978d5ba-e015-4889-a8b7-7a2891664492@app.fastmail.com
Whole thread Raw
In response to Re: [PATCH] Add tests for Bitmapset  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [PATCH] Add tests for Bitmapset
List pgsql-hackers
On Thu, Sep 11, 2025, at 2:48 AM, Masahiko Sawada wrote:
> On Mon, Sep 8, 2025 at 11:21 AM Burd, Greg <greg@burd.me> wrote:
>>
>>
>> > On Sep 5, 2025, at 2:43 PM, Nathan Bossart <nathandbossart@gmail.com> wrote:
>> >
>> > On Fri, Sep 05, 2025 at 10:48:21AM -0400, Burd, Greg wrote:
>> >> I looked at both radix tree and binary heap and how they use random sets when
>> >> testing.  Binary heap uses it to create different random sets of numbers to
>> >> use across multiple tests while radix tree has a single function that focuses
>> >> on randomized data.  I decided not to add randomization into the tests of
>> >> Bitmapset simply because I like avoiding non-deterministic behavior.  But in
>> >> tests I guess that can be helpful finding future unknown corner cases.  I'm
>> >> on the fence as to the value, your call.  :)
>> >
>> > I'm not too concerned about it.  We've lived without a dedicated test suite
>> > for Bitmapset for a very long time, so any amount of test coverage is an
>> > improvement.  Like you said, adding some randomization might be helpful for
>> > finding weird bugs we wouldn't have thought to test.  And, given the many,
>> > many machines that run the tests, IMHO it'd only help build even more
>> > confidence in the code.  If my suggestion inspires you to update the patch,
>> > great, but I'm fine with proceeding with what you already wrote, too.
>>
>> Nathan, thanks for considering the patch.  Honestly, I'm fine with it as is.
>> We can revisit later if needed.  This does what I'd intended, test and document
>> in code the API and implementation making future changes to that more
>> transparent.
>
> I appreciate your work on this. While I agree that adding more tests
> to  bitmapset.c is a good idea, I'm concerned about the minimal
> improvement in test coverage despite the addition of new test cases
> (only three lines of code are newly covered). Apart from adding some
> randomness to the tests we've discussed, given that we're implementing
> a dedicated test module for bitmapset.c, I would expect to see a more
> increase in test coverage.

Good point and thanks for taking the time to reply.  The only thing it identified
was a small issue fixed in b463288 so I'd not expect coverage to increase much.

I'll take a stab at adding some randomness to the tests and check the delta in
coverage.  Thanks for the nudge.  :)

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

Just for reference I started this not to increase coverage, which is a good
goal just not the one I had.  I was reviewing the API and considering some
changes based on other work I've done.  Now that I see how deeply baked in
this code is I think that's unlikely.  Maybe something else distinct for
bitmaps over 64-bit space at some point will be useful.  I wrote this code
just to capture the API in test form.

best,

-greg



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Amit Kapila
Date:
Subject: Re: Allow logical replication in the same cluster