Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

[Andreas Seltenreich]

Tom Lane writes:

> Andreas Seltenreich  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,1);
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

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

[Tom Lane]

Andreas Seltenreich  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,1);
> 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

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

[Andres Freund]

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

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

[Tom Lane]

Andreas Seltenreich  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

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

[Peter Geoghegan]

On Fri, Dec 18, 2015 at 1:23 PM, Andreas Seltenreich  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

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

[Andreas Seltenreich]

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