Re: Missing update of all_hasnulls in BRIN opclasses - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Missing update of all_hasnulls in BRIN opclasses
Date
Msg-id CAEze2Wj=DDFB5Akahz8qO-SwLm604Pds8EuW__6h2-aiQ+VQLA@mail.gmail.com
Whole thread Raw
In response to Missing update of all_hasnulls in BRIN opclasses  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: Missing update of all_hasnulls in BRIN opclasses  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On Fri, 21 Oct 2022 at 17:24, Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> Hi,
>
> While working on some BRIN code, I discovered a bug in handling NULL
> values - when inserting a non-NULL value into a NULL-only range, we
> reset the all_nulls flag but don't update the has_nulls flag. And
> because of that we then fail to return the range for IS NULL ranges.

Ah, that's bad.

One question though: doesn't (shouldn't?) column->bv_allnulls already
imply column->bv_hasnulls? The column has nulls if all of the values
are null, right? Or is the description of the field deceptive, and
does bv_hasnulls actually mean "has nulls bitmap"?

> Attached is a patch fixing this by properly updating the has_nulls flag.

One comment on the patch:

> +SET enable_seqscan = off;
> + [...]
> +SET enable_seqscan = off;

Looks like duplicated SETs. Should that last one be RESET instead?

Apart from that, this patch looks good.

- Matthias



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Avoid memory leaks during base backups
Next
From: Bharath Rupireddy
Date:
Subject: Re: thinko in basic_archive.c