matrixorigin / matrixorigin/matrixone

[Bug]: CREATE TABLE partitioned by HASH with TIME(6) column panics

Open
#25,500 1 comment 0 reactions 1 assignee Claimed by @ck89119 View on GitHub
area/partition deferred kind/bug
Dominant language
Go
Stars
1.9k
Forks
311
Avg merge
1d 3h
Merged PRs (30d)
768

Description

## Summary

On latest `main` (`a03bfc1b6`), creating a hash-partitioned table with a secondary index that includes a `TIME(6)` column returns an internal panic. MySQL 8.0.45 accepts the same DDL.

This was found while exploring the remaining window-function partition-table coverage; the failure happens during `CREATE TABLE`, before any window query runs.

## Duplicate check

Searched before filing:

- `partition time index panic`
- `TIME(6) partition index`
- `tree.Statement is nil`

No duplicate result-correctness/DDL panic issue was found. #25030 is about checkpoint dump restore for RANGE/LIST partition tables and is not the same issue.

## Reproduce

```sql
DROP DATABASE IF EXISTS mysql_compat_partition_time_decimal_min;
CREATE DATABASE mysql_compat_partition_time_decimal_min;
USE mysql_compat_partition_time_decimal_min;

CREATE TABLE p_time_idx (
id int not null,
bucket int not null,
tenant int not null,
tm time(6) null,
primary key(tenant, bucket, id),
key idx_time(tenant, tm, id)
) PARTITION BY HASH(bucket) PARTITIONS 4;
```

## MySQL 8.0.45 result

```text
Query OK
```

## MatrixOne result

```text
ERROR 1105 (HY000): internal error: panic interface conversion: tree.Statement is nil, not *tree.CreateTable
```

Stack starts with:

```text
runtime.panicdottypeE
runtime.panicdottypeI
github.com/matrixorigin/matrixone/pkg/sql/compile.(*Scope).CreateTable
pkg/sql/compile/ddl.go:1919
```

## Expected behavior

MatrixOne should either support the DDL consistently with MySQL or return a normal unsupported-feature error. It should not panic with an internal `tree.Statement is nil` conversion error.

## Additional information

A simple hash-partitioned table with an integer secondary index works, so this is not a generic `PARTITION BY HASH + secondary index` failure. The issue is reproducible when a `TIME(6)` column participates in the secondary index.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.