[CBRD-XXXXX] Keep the group-by input page fixed while its bytes are borrowed

[xmilex-git]

Problem

Sort-based GROUP BY returns silently wrong rows: char/varchar group-by key columns come back as binary garbage while the row count and the aggregate values stay correct. No error, no warning.

It needs a join, a GROUP BY on columns from the joined side, and COUNT(DISTINCT ...) — the DISTINCT aggregate makes the query hash-ineligible, so it falls to the sort path. It only shows once the group-by sort spills.

'SMALL BURNISHED NICKEL'           19                    62
'\x00\x00\x01\x00\x00\x00\x08\x00\x00\r'          '\x00\x00\x01\x00\x00\x00\x10...'

Exactly 10 bytes of non-string data in a CHAR(10) column. Non-deterministic: the same statement returns clean rows on one execution and corrupt rows on the next, and the corrupt rows differ every time.

Root cause

qexec_gby_put_next() fixes an input list-file page and passes a pointer into it to qexec_gby_agg_tuple() with peek = PEEK, so fetch_val_list() makes the group-by DB_VALUEs borrow the page rather than copy it. The page is then unfixed at the end of the same loop iteration:

qexec_gby_agg_tuple (thread_p, info, data, peek);
info->input_recs++;
#if 1  /* SortCache */
  if (page)
    qmgr_free_old_page_and_init (thread_p, page, list_idp->tfile_vfid);
#endif

Those values are not consumed there. They are the group's output values, read later by qexec_gby_finalize_group_dim() — when a subsequent tuple opens a new group, or, for the final group, after sort_listfile() returns in qexec_groupby(). Once the sort spills, the unfixed frame is recycled before that read.

The discriminator is spill, not buffer size. Same plan, same query, ;trace on:

clean:   GROUPBY (hash: false, sort: true, page: 128,   ioread: 0,     rows: 27840)
corrupt: GROUPBY (hash: false, sort: true, page: 12112, ioread: 80765, rows: 1000)

data_buffer_size only decides whether the sort spills, which is why the effect is not monotonic in it.

Fix

Hold the borrowed page until its values have been consumed. struct groupby_state already carries fixed_page / fixed_vpid for exactly this, disabled behind #if 0 /* SortCache */; this restores them and moves the release to:

• just before the next tuple's values overwrite the borrowed ones (after that iteration's possible finalize);
• after the final qexec_gby_finalize_group_dim() in qexec_groupby();
• on the error path in qexec_clear_groupby_state().

At most one page stays fixed at a time. The original VPID is kept in a separate page_vpid because QFILE_GET_OVERFLOW_VPID() overwrites vpid.

The COPY paths — overflow tuples and A_sort_key — are unchanged; they already materialise their own copy.

Forcing peek = COPY was the one-line alternative. It was not taken: extending the fix range also lets consecutive tuples that share a page skip the re-fix, and measured faster.

Verification

OptDebug build (11.5.0.2405-a2c3e03), data_buffer_size=16M, part_s 1,000,000 rows joined to partsupp_s 4,000,000 rows, 1,000 groups.

	corrupt runs
before	6/6
after	0/8

TPC-H SF10 Q16 at data_buffer_size=512M:

	corrupt runs
before, a2c3e03	4/10
before, 607f1ee9	3/10
after	0/5

Correctness: the fixed build's 27,840 Q16 rows are SHA-256 identical to the known-good result produced at data_buffer_size=8192M, where the sort does not spill.

No assertion fires in the OptDebug build before or after — the dangling read lands in a live buffer frame, so nothing detects it.

Performance, same OptDebug build and identical conf, 3 runs of the reproducer:

	wall
before	44.11 / 44.47 / 44.84 s
after	34.16 / 35.89 / 36.95 s

Release-build performance not measured.

Not a regression

Reproduces on 607f1ee9 (2026-07-24) as well as on a2c3e03. The peek = PEEK shortcut and the per-tuple unfix are long-standing. In particular this is unrelated to the loaddb --no-logging-index parallel index build (PR CUBRID#7504 / CBRD-27071): that code is not in 607f1ee9, the affected database was never loaded through that path, and a full heap scan of the base table returns no bad rows.

Reproducer

select p_brand, p_type, p_size, count(distinct ps_suppkey)
from partsupp_s, part_s
where p_partkey = ps_partkey
group by p_brand, p_type, p_size;

Full setup is in the linked issue's Repro section. Run it several times — it is non-deterministic.

[xmilex-git]

Recreating: the fork's develop was 4 upstream commits behind, so the diff included unrelated commits. develop has been fast-forwarded to a2c3e03 and the PR is reopened with the single commit.

[github-actions]

⚠️ TC Branch Finalize Failed for cubrid-testcases-private-ex

Failed to process tc/pr-166.
Please check the workflow run for details.

[github-actions]

⚠️ TC Branch Finalize Failed for cubrid-testcases

Failed to process tc/pr-166.
Please check the workflow run for details.