Re: BUG #17774: Assert triggered on brin_minmax_multi.c

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, tharakan(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17774: Assert triggered on brin_minmax_multi.c
Date: 2023-02-11 19:00:37
Message-ID: 20230211190037.m2rbm674zglr2d3m@erthalion.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On Thu, Feb 09, 2023 at 05:18:47PM +0100, Tomas Vondra wrote:
>
> I believe the bug is pretty trivial - the code applies the netmask
> incorrectly, so that with 127.0.0.1/0 it ends with 0.0.0.1, and because
> it assumes 0.0.0.1 < 0.0.0.0 it ends with negative delta.
>
> In particular, the issue is that the code does this:
>
> lena = ip_bits(ipa); -- 0
> len = ip_addrsize(ipa); -- 4
>
> for (for (i = 0; i < len; i++)
> {
> nbits = lena - (i * 8);
> ...
> mask = (0xFF << (8 - nbits));
> ...
> }
>
> But for 127.0.0.1/0 we get lena=0, so for i>0 nbits gets negative, and
> the shift is probably going to do something silly (not sure what
> exactly, but AFAICS it's undefined behavior).
>
> Attached is a fixup that resolves this failure for me. I need to look a
> bit closer if there are some other issues (e.g. with the float rounding
> errors, etc.).

Thanks, the fix looks good and solves the issue. With the patch applied
after a quick round of testing I haven't found any failures so far,
whether due to float arithmetic or something else.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-02-12 09:46:19 BUG #17787: Seriously wrong value of pg_class.reltuples for FTS GIN index after VACUUM (INDEX_CLEANUP)
Previous Message Heikki Linnakangas 2023-02-11 10:58:02 Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate