From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Missing update of all_hasnulls in BRIN opclasses |
Date: | 2022-10-21 15:50:32 |
Message-ID: | CAEze2Wj=DDFB5Akahz8qO-SwLm604Pds8EuW__6h2-aiQ+VQLA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 21 Oct 2022 at 17:24, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-10-21 16:00:16 | Re: thinko in basic_archive.c |
Previous Message | Bharath Rupireddy | 2022-10-21 15:32:04 | Re: Avoid memory leaks during base backups |