GROUP_CONCAT(DISTINCT)` fails to deduplicate when `tmp_memory_table_size=0`

GROUP_CONCAT(DISTINCT ...) returns duplicate values when tmp_memory_table_size=0 forces the internal temp table directly to Aria, bypassing HEAP. The deduplication is silently skipped, producing incorrect results.

Reproducer

CREATE TABLE t1 (

  pk INT AUTO_INCREMENT PRIMARY KEY,

  a VARCHAR(100) NOT NULL,

  v INT NOT NULL

);

INSERT INTO t1 (a, v) SELECT LPAD(seq, 4, '0'), seq FROM seq_1_to_50;

INSERT INTO t1 (a, v) SELECT a, v+100 FROM t1 ORDER BY pk;

-- 100 rows, 50 distinct values of `a`

SELECT COUNT(*), COUNT(DISTINCT a) FROM t1;

-- 100, 50

-- Correct: HEAP temp table path

SET tmp_memory_table_size=DEFAULT;

SELECT LENGTH(GROUP_CONCAT(DISTINCT a ORDER BY a)) AS gc_len FROM t1;

-- 249 (50 values * 4 chars + 49 commas)

-- Bug: direct Aria temp table path

SET tmp_memory_table_size=0;

SELECT LENGTH(GROUP_CONCAT(DISTINCT a ORDER BY a)) AS gc_len FROM t1;

-- 499 (100 values, no deduplication — WRONG, expected 249)

DROP TABLE t1;

Expected result

gc_len = 249 in both cases (50 distinct 4-character values joined with commas).

Actual result

With tmp_memory_table_size=0: gc_len = 499 — all 100 rows are concatenated without deduplication, as if DISTINCT were ignored.

Notes

• Reproduces with VARCHAR, TEXT, and INT columns — not specific to any data type.
• SELECT DISTINCT and UNION DISTINCT work correctly at tmp_memory_table_size=0; only GROUP_CONCAT(DISTINCT) is affected.
• The DISTINCT deduplication in GROUP_CONCAT uses a separate internal temp table for the unique check. When that temp table is forced directly to Aria (never created as HEAP first), the dedup appears to be skipped entirely.