Request a Demo
Home   >   mailing lists

Re: Small and unlikely overflow hazard in bms_next_member() - Mailing list pgsql-hackers

From David Rowley
Subject Re: Small and unlikely overflow hazard in bms_next_member()
Date
Msg-id CAApHDvrvvq_m+nRwjsOpCsFa4EtVtmvJX7zAD=Siria-x6DpbQ@mail.gmail.com
Whole thread
In response to Re: Small and unlikely overflow hazard in bms_next_member()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Small and unlikely overflow hazard in bms_next_member()
List pgsql-hackers
Tree view 
On Thu, 2 Apr 2026 at 17:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>         Assert(prevbit <= a->nwords * BITS_PER_BITMAPWORD);

> but if the bitmapset were large enough to accommodate INT_MAX
> as a member then a->nwords * BITS_PER_BITMAPWORD must overflow.

I missed that one. That's annoying. Even "prevbit = a->nwords *
BITS_PER_BITMAPWORD - 1;" is undefined if it wraps due to the signed
maths.

> I don't think we should add cycles here for this purpose.

I'm not keen on slowing things down for this either. I did do some
experiments in [1] that sees fewer instructions from using 64-bit
maths. I might go off and see if there are any wins there that also
give us the INT_MAX fix. It's not great effort to reward ratio
though...

David

[1] https://godbolt.org/z/Eh1vzssq7

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Better shared data structure management and resizable shared data structures
Next
From: Masahiko Sawada
Date:
Subject: Re: Initial COPY of Logical Replication is too slow