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

On Sun, Jul 26, 2015 at 9:55 PM, Andreas Seltenreich <seltenreich@gmx.de> wrote:
> 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.  Someone more knowledgeable might want
> to take a look at them...
>
> -- FailedAssertion("!(outer_rel->rows > 0)", File: "indxpath.c", Line: 1911)
> -- sample query:
>     select
>       rel1925354.loid as c0,
>       rel1925353.version as c1
>     from
>       (select
>             rel1925352.aa as c0,
>             rel1925352.aa as c1
>           from
>             public.b as rel1925352
>           where (rel1925352.bb is NULL)
>             and (rel1925352.bb < rel1925352.bb)) as subq_303136
>           inner join pg_catalog.pg_stat_ssl as rel1925353
>           on (subq_303136.c0 = rel1925353.pid )
>         right join pg_catalog.pg_largeobject as rel1925354
>         on (subq_303136.c0 = rel1925354.pageno )
>     where (rel1925353.clientdn !~ rel1925353.clientdn)
>       and (rel1925353.cipher <= rel1925353.clientdn);
>
> ,----[ git bisect ]
> |   first bad commit: [3f8c23c4d31d4a0e801041733deb2c7cfa577b32] Improve
> |   predtest.c's ability to reason about operator expressions.
> `----
>
> -- FailedAssertion("!(!bms_is_empty(phinfo->ph_eval_at))", File: "placeholder.c", Line: 109)
> -- sample query:
>     select
>       rel1600276.viewowner as c0,
>       rel1600274.maxwritten_clean as c1,
>       rel1600275.n_tup_hot_upd as c2
>     from
>       pg_catalog.pg_stat_bgwriter as rel1600274
>           inner join pg_catalog.pg_stat_xact_all_tables as rel1600275
>           on (rel1600274.maxwritten_clean = rel1600275.seq_scan )
>         right join pg_catalog.pg_views as rel1600276
>           right join pg_catalog.pg_operator as rel1600277
>           on (rel1600276.viewname = rel1600277.oprname )
>         on (rel1600275.relname = rel1600277.oprname )
>     where 3 is not NULL;
>
> ,----[ git bisect ]
> |   first bad commit: [f4abd0241de20d5d6a79b84992b9e88603d44134] Support
> |   flattening of empty-FROM subqueries and one-row VALUES tables.
> `----
>
> -- FailedAssertion("!(key->sk_flags & 0x0080)", File: "brin_minmax.c", Line: 177)
> -- sample query:
>     select
>       rel167978.namecol as c0
>     from
>       information_schema.parameters as rel167972
>         left join public.student as rel167977
>           inner join public.brintest as rel167978
>           on (rel167977.age = rel167978.int4col )
>         on (rel167972.interval_precision = rel167977.age )
>     where rel167977.name <> rel167977.name;
> Footnotes:
> [1]  https://github.com/anse1/sqlsmith

This is really interesting stuff. I think that it would be possible to
extract self-contained test cases from your tool and those queries to
reproduce the failures. It is written that this tools connects to a
database to retrieve the schema, what is it exactly in the case of
those failures?
-- 
Michael