[sqlsmith] Failing assertions in spgtextproc.c

On Fri, Dec 18, 2015 at 1:23 PM, Andreas Seltenreich <seltenreich@gmx.de> wrote:

I do see two assertions in spgtextproc.c fail on occasion when testing
with sqlsmith:

TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)

I can't reproduce it reliably but looking at the coredumps, the failing
part of the expression is always

in->level == 0 && DatumGetPointer(in->reconstructedValue) == NULL

In all of the dumps I looked at, in->reconstructedValue contains a
zero-length text instead of the asserted NULL, and the tuples fed to
leaf_consistent()/inner_consistent() look like the one below.

Can you do this?:

(gdb) p debug_query_string

It's a global variable, often useful in these situations.

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Geoghegan writes:

Can you do this?:

(gdb) p debug_query_string

output below. Since sqlsmith ist no longer restricted to read-only
statements, the chances for reproduction are low :-/.

select
pg_catalog.pg_stat_get_buf_written_backend() as c0,
subq_1.c0 as c1,
subq_1.c0 as c2,
subq_1.c0 as c3
from
(select
(select ordinal_position from information_schema.parameters limit 1 offset 12)
as c0,
ref_2.t as c1
from
public.radix_text_tbl as ref_2
inner join pg_catalog.pg_stat_activity as ref_3
on (ref_2.t = ref_3.application_name )
where ref_2.t @@ cast(coalesce(ref_2.t, ref_3.client_hostname) as text)
limit 111) as subq_1,
lateral (select
subq_1.c0 as c0,
subq_2.c2 as c1,
56 as c2,
cast(coalesce(cast(coalesce((select pop from public.real_city limit 1 offset 34)
, subq_1.c0) as integer), subq_2.c0) as integer) as c3,
74 as c4,
(select unique1 from public.onek2 limit 1 offset 17)
as c5
from
(select
(select ordinal_position from information_schema.parameters limit 1 offset 27)
as c0,
sample_2.umoptions as c1,
sample_2.umserver as c2
from
pg_catalog.pg_user_mapping as sample_2 tablesample system (6.2)
where 49 is NULL) as subq_2
where cast(coalesce(subq_1.c0, subq_2.c0) as integer) is not NULL
limit 105) as subq_3
where ((select x from public.tt0 limit 1 offset 12)
<= subq_3.c0)
and (subq_3.c4 <= 30);

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andreas Seltenreich <seltenreich@gmx.de> writes:

I do see two assertions in spgtextproc.c fail on occasion when testing
with sqlsmith:
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)

Can you show us the definition of the index that's causing this,
and some samples of the data you're putting in it?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-12-19 07:04:09 +0100, Andreas Seltenreich wrote:

output below. Since sqlsmith ist no longer restricted to read-only
statements, the chances for reproduction are low :-/.

How many backends are concurrently writing data with sqlsmith? Just one?
If so, and possibly even otherwise, it might be worthwhile to set up
PITR and record the LSN at the beginning of transactions. That'd allow
to replay the state of the database to just before the failing xact.

Regards,

Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane writes:

Andreas Seltenreich <seltenreich@gmx.de> writes:

TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)

Can you show us the definition of the index that's causing this,
and some samples of the data you're putting in it?

Here's a recipe for triggering the former:

create table t(c text);
create index on t using spgist(c);
insert into t select '' from generate_series(1,10000);
set enable_seqscan to off; select count(1) from t;

I still think it's just the assertions being too strict.

regards,
Andreas

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andreas Seltenreich <seltenreich@gmx.de> writes:

Here's a recipe for triggering the former:

create table t(c text);
create index on t using spgist(c);
insert into t select '' from generate_series(1,10000);
set enable_seqscan to off; select count(1) from t;

Ah-hah. Thanks for the test case.

I still think it's just the assertions being too strict.

Yes, now I agree. Fix pushed.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers