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.