maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Hi Monty,

After you pushed the patch for lp:732124, test failures appeared in Buildbot
for test case pbxt.union.

Most were just that the pbxt union.result file needed same update as for
main.union. But there was one more issue:

    create table t1 (a int);
    insert into t1 values (1),(2),(3);
    create table t2 (a int);
    insert into t2 values (3),(4),(5);

    # ...

    SELECT SQL_CALC_FOUND_ROWS * FROM t1 UNION SELECT * FROM t2 LIMIT 2;
    select found_rows();

In pbxt.union, this now (after your patch) return 5. However, the result file
for main.union has a return value of 6, and the test succeeds with MyISAM.

The thing is ... the value that 5 PBXT returns is correct, and what MyISAM
does and what is in the result file is wrong. At least according to the
docs. The full query would return 5 rows (as it is union distinct), not 6...

What I will do is that I will fix the PBXT union.result to have the correct
value "5" to get the test suite to pass in Buildbot.

However, there seems to be some deeper problem here, given that MyISAM does
something different (and wrong?). There are also other cases that are wrong:

    SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT 1 UNION SELECT * FROM t2;
    a
    1
    3
    4
    5
    select found_rows();
    found_rows()
    6
    SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT 1 UNION SELECT * FROM t2 LIMIT 2;
    a
    1
    3
    select found_rows();
    found_rows()
    6

(the result should have been 5)

So maybe there are still bugs in the code? Or if this is a limitation of
SQL_CALC_FOUND_ROWS with UNION (there is a comment in the test case "# The
following examples will not be exact" that might hint at this), then we should
document this at least ...

 - Kristian.