pingcap / pingcap/tidb

Prepared-statement parameter inside max_count(?) / min_count(?) panics

Open
#70,817 3 comments 0 reactions 0 assignees View on GitHub
contribution severity/major sig/execution type/bug
Dominant language
Go
Stars
40.5k
Forks
6.2k
PR merge metrics
PR metrics pending

Description

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

```
CREATE TABLE t(v INT);
INSERT INTO t VALUES (1);

PREPARE s FROM 'SELECT max_count(?) FROM t';
SET @pv = 5;
EXECUTE s USING @pv;
-- ERROR 1105 (HY000): runtime error: invalid memory address or nil pointer dereference

```

### 2. What did you expect to see? (Required)

Ten-function control experiment: every classic aggregate (max/min/count/sum/avg/bit_or/ group_concat) executes fine; sum_int(?) is cleanly rejected by its type check; only max_count(?) / min_count(?) panic. Stack: AggFuncDesc.Split (descriptor.go:214, the file modified by the introducing commit) → ParamMarker.GetUserVar. The HAVING max_count(?) variant panics too; user-variable inlining (max_count(@pv)) does not.

### 3. What did you see instead (Required)

```
mysql> CREATE TABLE t(v INT);
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t VALUES (1);
Query OK, 1 row affected (0.01 sec)

mysql>
mysql> PREPARE s FROM 'SELECT max_count(?) FROM t';
Query OK, 0 rows affected (0.00 sec)

mysql> SET @pv = 5;
Query OK, 0 rows affected (0.00 sec)

mysql> EXECUTE s USING @pv;
ERROR 1105 (HY000): runtime error: invalid memory address or nil pointer dereference
```
### 4. What is your TiDB version? (Required)

```
| Release Version: v9.0.0-beta.2.pre-2174-g65ac2fad58-dirty
Edition: Community
Git Commit Hash: 65ac2fad582510b92d3c4b79999e48217c989737
Git Branch: master
UTC Build Time: 2026-08-30 15:18:00
GoVersion: go1.25.12
Race Enabled: false
Check Table Before Drop: false
Store: unistore
Kernel Type: Classic |

```

Contributor guide

Open the contributing guide

Research direction

Start at AggFuncDesc.Split in descriptor.go:214 and trace the prepared-statement path through ParamMarker.GetUserVar. Reproduce the SELECT max_count(?) and min_count(?) cases, including the HAVING variant, then add regression coverage showing these queries no longer panic while the existing aggregate control cases retain their behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, sql
Domain
databases
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.