Bummer, I don't know how this has stalled for so long

I've pushed it to a feature tree for buildbot testing, once that has run I will push it to 10.1.

Ehm, this really does not work:

# This one completes immediately ( < 1 ms).

SELECT master_gtid_wait('1-1-1');

let $wait_time = query_get_value(SHOW STATUS LIKE 'Master_gtid_wait_time', Value, 1);

eval SELECT floor($wait_time / 1000) AS Master_gtid_wait_time_milliseconds;

SELECT master_gtid_wait('2-1-2', 0.5);

# (0.5-0.6 seconds)

eval SELECT floor($wait_time / 100000) AS Master_gtid_wait_time_tenths_of_a_second;

Those times will fluctuate a lot depending on load on the test machine (as
seen in buildbot).

And did you test that the counters are reset to 0 when the test starts, so
that they values do not depend on what happened in earlier tests that ran
before this test?

Also, main.max_statement_time fails (but that's easy to fix).

https://github.com/MariaDB/server/pull/21

> Those times will fluctuate a lot depending on load on the test machine (as seen in buildbot).

Increased time windows a lot. The immediate case is a event is pushed to the master before master_gtid_wait is called on the slave. The 0.5 case is the timeout occurs on the slave master_gtid_wait. Is there a way to write these sort of test cases?

> And did you test that the counters are reset to 0

I'm only looking at the session status variables on a new connection.

> Also, main.max_statement_time fails (but that's easy to fix).

I don't see that in my patch.

I've merged it into 10.1 and pushed to bb-10.1-knielsen for a buidbot run.
If everything looks ok, I'll push to main 10.1 tomorrow.

Pushed to 10.1.4, thanks Daniel!