Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Seltenreich <seltenreich(at)gmx(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c
Date: 2015-07-28 18:39:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:

> Bottom line is that somebody failed to consider the possibility of a
> null comparison value reaching the BRIN index lookup machinery.
> The code stanza that's failing supposes that only IS NULL or IS NOT NULL
> tests could have SK_ISNULL set, but that's just wrong.

I think the easiest way to solve this is to consider that all indexable
operators are strict, and have the function return false in that case.
The attached patch implements that. (In a quick check, the only
non-strict operator in the regression database is <%(point,widget),
which seems okay to ignore given that the type itself is only part of
pg_regress. I wonder what would happen if the regression tests defined
an index using that operator.)

What btree actually does is precompute a "qual_ok" property at
scan-restart time, which seems pretty clever (maybe too much). I think
something like _bt_preprocess_keys should probably be applied to BRIN
scans someday.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
brin-nulls.patch text/x-diff 1.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-07-28 18:39:43 Re: TODO: replica information functions
Previous Message Josh Berkus 2015-07-28 18:35:52 TODO: replica information functions