Conversation
gkodinov
reviewed
Sep 28, 2026
gkodinov
left a comment
Member
There was a problem hiding this comment.
Thank you for your contribution! This is a preliminary review.
Very close, but I'd like to see a clearer test case before I approve it.
gkodinov
requested changes
Sep 28, 2026
HAVING can read stale aggregate and field values when grouped rows are copied into a second temporary table for DISTINCT. Rechecking the same condition during duplicate removal can then discard qualifying rows. Bind HAVING references to the stored values of the completed groups. Evaluate the condition while writing the DISTINCT table, and avoid attaching or evaluating it again against that table. Add one grouped query with two qualifying groups that produce the same output and one rejected group. Check that DISTINCT returns the single qualifying row. Use the default test environment without extra session settings, a separate database or equivalent query variants. Bug report: https://jira.mariadb.org/browse/MDEV-40779
DISTINCT + char_length(SPACE(AVG(…))) + HAVING returns empty for one insertion order of the same rows
DerZc
force-pushed
the
fix-mdev-40779
branch
from
September 29, 2026 08:20
c0016d3 to
84b959a
Compare
gkodinov
approved these changes
Sep 29, 2026
gkodinov
left a comment
Member
There was a problem hiding this comment.
LGTM. Thanks. Please stand by for the final review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HAVING can read stale aggregate and field values when grouped rows are
copied into a second temporary table for DISTINCT. Rechecking the condition
during duplicate removal can discard qualifying rows.
Bind HAVING to the stored values of the completed groups. Evaluate it while
writing the DISTINCT table, and avoid attaching or evaluating it again
against that table.
Bug report: https://jira.mariadb.org/browse/MDEV-40779
Regression coverage
Reduce the addition to
main.func_groupfrom 67 lines to five: an issueheader, table creation, three input rows, one query and cleanup. Two groups
satisfy HAVING and produce the same output; a third group fails HAVING. The
expected DISTINCT result is one row,
(2, 2).Remove the extra InnoDB include, session settings, separate database,
sorting directives, equivalent query variants and manual prepared statements.
The original source fix and existing test contents are preserved.
Validation
On current
11.4atf49e838d367f2154b3edb43effa99ff9eb0d8602:main.func_grouponly because thenew query returns no rows instead of
(2, 2).main.func_group,main.group_by,main.having,main.select,main.distinctandmain.view.main.func_grouppasses with the view protocol.with the prepared-statement protocol, including its automatic repeated
SELECT execution. The existing full
main.func_grouptest disables thatprotocol at its start.