----- Original Message -----
Daniel Black <notifications@github.com> writes: What do you think of something like
binlog_commit_trigger_count binlog_commit_trigger_timeout
instead ?
to maintain consistency with binlog_group_commits... binlog_group_commit_trigger_count binlog_group_commit_trigger_timeout binlog_group_commit_reason_immediate removed ref: https://github.com/openquery/mariadb-server/commit/1d5220d1124111f563f9faec3...
If not, maybe just have a single status variable, like
binlog_commit_trigger_lock_wait
done.
So this increments the global status variables directly, I think? How does the thread locking work? Is it possible for a reader to see a corrupt value (eg. one word of the old value and one word of the new) on 32-bit platform?
Incrementing of counters was already under LOCK_prepare_ordered. Used this lock in the status retrieval and made sure it didn't overlap with the LOCK_commit_ordered used by the other binlog status variables. https://github.com/openquery/mariadb-server/commit/dd7026a703aabdbe0430bf5f3...
With respect to the test cases: Can you please comment yourself on the different places where you added output of the status variables, and explain why this output will always be the same, no matter how threads are scheduled on the machine running the test? (This is the critical part of most tests related to replication; because of the inherently multi-threaded nature of such tests, a lot of care is needed to make sure the test will not produce different output on different test runs depending on the speed of the host or how threads are scheduled on a loaded machine).
Added: https://github.com/openquery/mariadb-server/commit/0695fdd9df3501a02ae473c23... -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.