Обсуждение: [sqlsmith] Failing assertions in spgtextproc.c
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. ,---- | (gdb) p *in | $1 = {scankeys = 0x60a3ee0, nkeys = 1, reconstructedValue = 101373680, level = 0, | returnData = 1 '\001', allTheSame = 1 '\001', hasPrefix = 0 '\000', prefixDatum = 0, nNodes = 8, | nodeLabels = 0x37b6768} | (gdb) x ((text *)in->reconstructedValue)->vl_len_ | 0x60ad6f0: 0x00000010 | (gdb) p *(text *)in->scankeys[0]->sk_argument | $2 = {vl_len_ = "0\000\000", vl_dat = 0x855950c "sqlsmith~", '\177' <repeats 8123 times>, "\020 "} | (gdb) p in->nodeLabels[0] | $3 = 65535 `---- Maybe these assertions are just too strict? I don't see the code misbehaving when relaxing them to reconstrValue != NULL && VARSIZE_ANY_EXHDR(reconstrValue) == in->level || in->level == 0 regards, Andreas
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
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 asc1 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) limit111) as subq_1, lateral (select subq_1.c0 as c0, subq_2.c2 as c1, 56 as c2, cast(coalesce(cast(coalesce((selectpop 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 offset17)as c5 from (select (select ordinal_position from information_schema.parameters limit 1 offset27)as c0, sample_2.umoptions as c1, sample_2.umserver as c2 from pg_catalog.pg_user_mappingas 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);
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
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
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
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