roachtest/sqlsmith: a bug with propagating precise integer width into the filter

[cockroach-teamcity]

roachtest.sqlsmith/setup=seed-vec/setting=vec failed with artifacts on release-21.2 @ 24021ba163e4ac438b169d575cf1527a4aae394d:

create table t (_interval interval, _int4 int4, _int8 int8, index (_int8));
insert into t values ('1 day'::interval, 1, 1);
select t2.* from t@t__int8_idx as t1 join t@t__int8_idx as t2 on t1._int8 = t2._int4 where (t2._interval / t1._int8) in ('1 day':::INTERVAL);

Reproduce

See: roachtest README

/cc @cockroachdb/sql-queries

This test on roachdash | Improve this report!

[yuzefovich]

The bug is present on 21.1.9 but not on 20.2.16, removing the release-blocker label.

[yuzefovich]

EXPLAIN tells us that the filter divides by INT4:

  • hash join
  │ equality: (_int8) = (_int4)
  │
  ├── • scan
  │     missing stats
  │     table: t@t__int8_idx
  │     spans: FULL SCAN
  │
  └── • filter
      │ filter: (_interval / _int4) = '1 day'
      │
      └── • index join
          │ table: t@primary
          │
          └── • scan
                missing stats
                table: t@t__int8_idx
                spans: FULL SCAN

yet during the execution we divide by INT8:

ERROR: internal error: unexpected error from the vectorized engine: interface conversion: coldata.Column is coldata.Int32s, not coldata.Int64s
SQLSTATE: XX000
DETAIL: stack trace:
github.com/cockroachdb/cockroach/pkg/sql/colexecerror/error.go:88: func1()
runtime/panic.go:965: gopanic()
runtime/iface.go:261: panicdottypeE()
runtime/iface.go:271: panicdottypeI()
github.com/cockroachdb/cockroach/pkg/col/coldata/vec.go:243: Int64()
github.com/cockroachdb/cockroach/pkg/sql/colexec/colexecproj/proj_non_const_ops.eg.go:18189: func1()
github.com/cockroachdb/cockroach/pkg/sql/colmem/allocator.go:301: PerformOperation()
github.com/cockroachdb/cockroach/pkg/sql/colexec/colexecproj/proj_non_const_ops.eg.go:18179: Next()
github.com/cockroachdb/cockroach/pkg/sql/colexec/colexecsel/selection_ops.eg.go:9176: Next()
github.com/cockroachdb/cockroach/pkg/sql/colexec/colexecbase/simple_project.go:125: Next()
...

My guess is that we're missing the propagation of the integer's width during planning.

[mgartner]

It looks like the width of the integer is propagated correctly, we just don't have a projDivIntervalInt32Op. There is only projDivIntervalInt64Op, so that it used by default in proj_non_const_ops.eg.go. I haven't yet figured out why the operator for interval / int4 and interval / int2 are missing from the generated code - there are operators for decimal / int[2,4,8]: projDivDecimalInt16Op, projDivDecimalInt32Op, projDivDecimalInt64Op.

[yuzefovich]

I see, indeed. We forgot to define some combinations in registerBinOpOutputTypes in execgen/overloads_bin.go.

[mgartner]

It's rare to come across this case because most INTERVAL / INT[2,4] expressions are retyped to INTERVAL / INT8 here. I think the fix is simple: #74882.