bug: range scan datum deserialization panicked at 'assertion failed: self.remaining() >= dst.len()' #7158
Comments
BugenZhao
changed the title
assertion failed: self.remaining() >= dst.len()
BugenZhao
changed the title
|
Which query caused this? Is it the last query in the |
|
Seem so, didn't find other related context 😟 |
65 tasks
|
|
|
|
The failure on meta is caused by compute node exiting unexpectedly. The root cause should be panic on the compute node. I guess there's something wrong with the implementation of ser/de of some kind of data type. 🤔 |
|
First bad commit: da6114d from git bisect. |
|
Changing CREATE TABLE partsupp (
ps_partkey INTEGER,
ps_suppkey INTEGER,
ps_availqty INTEGER,
ps_supplycost NUMERIC,
ps_comment VARCHAR,
PRIMARY KEY (ps_partkey, ps_suppkey)
);
CREATE TABLE orders (
o_orderkey BIGINT,
o_custkey INTEGER,
o_orderstatus VARCHAR,
o_totalprice NUMERIC,
o_orderdate DATE,
o_orderpriority VARCHAR,
o_clerk VARCHAR,
o_shippriority INTEGER,
o_comment VARCHAR,
PRIMARY KEY (o_orderkey)
);
CREATE MATERIALIZED VIEW m5 AS SELECT 0::bigint AS col_0 FROM partsupp;
SELECT
1
FROM
m5 JOIN orders ON m5.col_0 = orders.o_orderkey
GROUP BY
m5.col_0,
orders.o_totalprice
HAVING
SMALLINT '27538' = m5.col_0;output Range scan is using Edit, the query plan is different, may not be the reason, continue investigating...: |
|
In the query: CREATE TABLE partsupp (
ps_partkey INTEGER,
ps_suppkey INTEGER,
ps_availqty INTEGER,
ps_supplycost NUMERIC,
ps_comment VARCHAR,
PRIMARY KEY (ps_partkey, ps_suppkey)
);
CREATE TABLE orders (
o_orderkey BIGINT,
o_custkey INTEGER,
o_orderstatus VARCHAR,
o_totalprice NUMERIC,
o_orderdate DATE,
o_orderpriority VARCHAR,
o_clerk VARCHAR,
o_shippriority INTEGER,
o_comment VARCHAR,
PRIMARY KEY (o_orderkey)
);
CREATE MATERIALIZED VIEW m5 AS SELECT 0::int AS col_0 FROM partsupp;
SELECT
1
FROM
m5 JOIN orders ON m5.col_0 = orders.o_orderkey
GROUP BY
m5.col_0,
orders.o_totalprice
HAVING
SMALLINT '27538' = m5.col_0;
However in Edit: Seems yes, it should be |
|
create table t1(x int);
create table t2(x bigint);
insert into t1 values(1);
insert into t2 values(1);
create index i1 on t1(x);
create index i2 on t2(x);
explain select * from i1 join i2 using(x) where x=1;
QUERY PLAN
-------------------------------------------------------------------------------------
BatchLookupJoin { type: Inner, predicate: i1.x::Int64 = i2.x AND (i2.x = 1:Int32) }
└─BatchExchange { order: [], dist: Single }
└─BatchProject { exprs: [i1.x, i1.x::Int64] }
└─BatchScan { table: i1, columns: [x], scan_ranges: [x = Int32(1)] }
(4 rows)
select * from i1 join i2 using(x) where x=1; -- panicHmm actually this triggered a different panic happenning in lookup join |
|
IIRC there are casts when building scan_ranges, so the OP's panic should not occur 🤔 |
|
It's the InputRef that has a wrong type 🥸 fixing... |
|
It is a bug of |
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
PlanLocal logs from running gist below
compute-node-5688.log
meta-node-5690.log
frontend-4566.log
To Reproduce
Expected behavior
No response
Additional context
https://buildkite.com/risingwavelabs/main-cron/builds/292#018574f6-e819-41db-ba51-80363d49c625
The text was updated successfully, but these errors were encountered: