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

Andreas Seltenreich <seltenreich@gmx.de> writes:
> when running my random query generator contraption[1] against the
> regression database of 9.5 or master, it occasionally triggers one of
> the following three assertions.

Very very cool tool!  Please keep doing that testing.

The first two seem to be planner problems, so I'll take responsibility for
digging into those.  But the third appears to be plain old brain fade in
the BRIN code.  It can be reproduced by

regression=# explain select * from brintest where int4col = NULL::integer::information_schema.cardinal_number;
                               QUERY PLAN                                          
 
--------------------------------------------------------------------------------
----------------Bitmap Heap Scan on brintest  (cost=52.01..56.02 rows=1 width=339)  Recheck Cond: (int4col =
((NULL::integer)::information_schema.cardinal_number
)::integer)  ->  Bitmap Index Scan on brinidx  (cost=0.00..52.01 rows=1 width=0)        Index Cond: (int4col =
((NULL::integer)::information_schema.cardinal_nu
mber)::integer)
(4 rows)

regression=# select * from brintest where int4col = NULL::integer::information_schema.cardinal_number;
server closed the connection unexpectedly

or you can do it like this:

regression=# select * from brintest where int4col = (select NULL::integer);
server closed the connection unexpectedly

or you could do it with a join to a table containing some null values.

You need some complication because if you just write a plain null literal:

regression=# explain select * from brintest where int4col = NULL::integer;                                QUERY PLAN
                       
 
------------------------------------------------------------------Result  (cost=0.00..106.30 rows=1 width=339)
One-TimeFilter: NULL::boolean  ->  Seq Scan on brintest  (cost=0.00..106.30 rows=1 width=339)
 
(3 rows)

the planner knows that int4eq is strict so it reduces the WHERE clause
to constant NULL and doesn't bother with an indexscan.

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.
        regards, tom lane