MDEV-40692 GROUP_CONCAT with an OFFSET that reaches past the last row of a group answers differently depending on how many times the result is asked for - #5721
Conversation
|
|
| # Regression: bug_40692 | ||
| --disable_query_log | ||
| --disable_result_log | ||
| --disable_warnings | ||
| SET NAMES utf8mb4; |
There was a problem hiding this comment.
Please refer to the comment that I just posted to #5722 for a similarly constructed test file.
There was a problem hiding this comment.
Thanks, I've applied the same feedback here. The files are now named group_concat_offset.test and group_concat_offset.result, and the test uses normal query, result, column-name, and warning output. I removed the unnecessary character-set setting and --query wrappers as well.
The test now covers both ORDER BY and DISTINCT without ORDER BY. It keeps the repeated evaluation through HAVING and the select list, and uses QUOTE() so the expected empty string is visible as '' in the result file. Both cases fail on unmodified 11.4 and pass with the fix. main.func_gconcat, main.func_group, main.group_by, and main.select also passed.
… of a group answers differently depending on how many times the result is asked for GROUP_CONCAT with ORDER BY or DISTINCT and an OFFSET beyond the end of the group can change its result when evaluated again. A query that evaluates the aggregate for HAVING and then for the select list can therefore expose inconsistent values. The tree or unique-filter traversal is only marked finalized by the row-output callback. If OFFSET consumes every row, that callback does not finalize the result. A subsequent evaluation traverses the same rows again with already-consumed LIMIT/OFFSET state. Mark ordered-tree materialization finalized immediately after its traversal finishes. Apply the same finalization to DISTINCT materialization without ORDER BY. Reuse the finalized result on subsequent evaluations, including traversals that produce no output rows. The regression evaluates GROUP_CONCAT in HAVING and again in the select list with an OFFSET that consumes the entire group. It checks both the ordered-tree path and DISTINCT without ORDER BY. QUOTE makes the expected empty string visible as ''. SQL statements, column headings, results, and warnings use normal MTR output. Bug report: https://jira.mariadb.org/browse/MDEV-40692
8ca2c82 to
c9fdc04
Compare
3 participants
GROUP_CONCAT with ORDER BY or DISTINCT and an OFFSET beyond the end of the group can change its result when evaluated again. A query that evaluates the aggregate for HAVING and then for the select list can therefore expose inconsistent values.
Bug report: https://jira.mariadb.org/browse/MDEV-40692
Root cause
The tree or unique-filter traversal is only marked finalized by the row-output callback. If OFFSET consumes every row, that callback does not finalize the result. A subsequent evaluation traverses the same rows again with already-consumed LIMIT/OFFSET state.
Changes
Regression coverage
The regression evaluates GROUP_CONCAT in HAVING and again in the select list with an OFFSET that consumes the entire group. It checks both the ordered-tree path and DISTINCT without ORDER BY. QUOTE makes the expected empty string visible as ''. SQL statements, column headings, results, and warnings use normal MTR output.
mysql-test/main/group_concat_offset.resultmysql-test/main/group_concat_offset.testValidation
On
11.4atd10e5d726799b1cd57cc866f40aad68c720803da:main.group_concat_offsetfailed on the unchanged target branch and passed with this fix.main.func_group,main.group_by,main.select,main.func_gconcat.