On Sun, Jul 26, 2015 at 9:55 PM, Andreas Seltenreich <seltenre...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
