Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.11.1
-
None
Description
On the first ever upload of MariaDB 10.11 to Debian, I noticed that various tests that compare the JSON output from the optimizer fails with mismatches on armel and armhf builds (amd64 and arm64 pass):
Failing test(s): main.rowid_filter_innodb main.analyze_stmt_orderby main.explain_json_format_partitions main.cte_recursive main.derived_cond_pushdown main.order_by main.rowid_filter main.intersect main.except main.except_all
main.except_all w5 [ fail ]
|
Test ended at 2023-01-12 20:20:18
|
|
|
CURRENT_TEST: main.except_all
|
--- /<<PKGBUILDDIR>>/mysql-test/main/except_all.result 2022-11-14 18:10:21.000000000 +0000
|
+++ /<<PKGBUILDDIR>>/mysql-test/main/except_all.reject 2023-01-12 20:20:18.132443098 +0000
|
@@ -115,13 +115,9 @@
|
ANALYZE format=json select * from ((select a,b from t1) except all (select c,d from t2)) a;
|
ANALYZE
|
{
|
- "query_optimization": {
|
- "r_total_time_ms": "REPLACED"
|
- },
|
"query_block": {
|
"select_id": 1,
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -146,7 +142,6 @@
|
"query_block": {
|
"select_id": 2,
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -169,7 +164,6 @@
|
"select_id": 3,
|
"operation": "EXCEPT",
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -199,13 +193,9 @@
|
ANALYZE format=json select * from ((select a from t1) except all (select c from t2)) a;
|
ANALYZE
|
{
|
- "query_optimization": {
|
- "r_total_time_ms": "REPLACED"
|
- },
|
"query_block": {
|
"select_id": 1,
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -230,7 +220,6 @@
|
"query_block": {
|
"select_id": 2,
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -253,7 +242,6 @@
|
"select_id": 3,
|
"operation": "EXCEPT",
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -469,9 +457,6 @@
|
ANALYZE format=json (select a,b,e,f from t1,t3) except all (select c,d,g,h from t2,t4);
|
ANALYZE
|
{
|
- "query_optimization": {
|
- "r_total_time_ms": "REPLACED"
|
- },
|
"query_block": {
|
"union_result": {
|
"table_name": "<except1,2>",
|
@@ -483,7 +468,6 @@
|
"query_block": {
|
"select_id": 1,
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -525,7 +509,6 @@
|
"select_id": 2,
|
"operation": "EXCEPT",
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -569,13 +552,9 @@
|
ANALYZE format=json select * from ((select a,b,e,f from t1,t3) except all (select c,d,g,h from t2,t4)) t;
|
ANALYZE
|
{
|
- "query_optimization": {
|
- "r_total_time_ms": "REPLACED"
|
- },
|
"query_block": {
|
"select_id": 1,
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -600,7 +579,6 @@
|
"query_block": {
|
"select_id": 2,
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
@@ -642,7 +620,6 @@
|
"select_id": 3,
|
"operation": "EXCEPT",
|
"r_loops": 1,
|
- "r_total_time_ms": "REPLACED",
|
"nested_loop": [
|
{
|
"table": {
|
|
|
mysqltest: Result length mismatch
|
Logs:
- https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=armel&ver=1%3A10.11.1-1%7Eexp1&stamp=1673554836&raw=0
- https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=armhf&ver=1%3A10.11.1-1%7Eexp1&stamp=1673555764&raw=0
This is somewhat similar to MDEV-11711 that had mismatches in JSON output on armhf only.
This is also similar to MDEV-8981 and MDEV-11866 where the issue was specifically the row
"r_total_time_ms": "REPLACED",
|
Jira MDEV-20538 is the newest in this category and only one I found still open (assigned to psergei).
Attachments
Issue Links
- is caused by
-
MDEV-28926 Make ANALYZE FORMAT=JSON show time spent in the query optimizer
-
- Closed
-
- relates to
-
-
- Open
-
-
-
- Closed
-
Activity
I had a look at the C++ and while resturning std::chrono::time_point was easy I didn't want to restructure it enough to go back to getting intervals and returning difference.
I found that clock_gettime is a vdso function linux on all architectures (except hppa) and this is what's used by my_interval_timer.
lizardo, is this acceptable? https://github.com/MariaDB/server/pull/2448
AdrianBunk, If not acceptable, could my_timer_cycles would return my_timer_nanoseconds (rather than milliseconds) be acceptable?
For the record, I have not encountered this failure on Launchpad or Debian builders since https://github.com/MariaDB/server/pull/2448 was backported to Debian in https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/340b190ac8a38dc60e176b136966229d40d14b2b
@danblack Your first test does not work due to MY_ADD_TESTS having SET(ARG_EXT "c"). That's likely easier to test by someone who understands your build system better.
Using std::chrono::high_resolution_clock is not my suggestion, it's from the TODO in the comment above my_timer_cycles() in include/my_rdtsc.h. Based on the Notes at https://en.cppreference.com/w/cpp/chrono/high_resolution_clock std::chrono::steady_clock might be a better option.