maria-developers team mailing list archive
Mailing list archive
Re: [server] Mdev 7802 binlog groupcommit stats (#30)
----- Original Message -----
> Daniel Black <notifications@xxxxxxxxxx> writes:
> What do you think of something like
> instead ?
to maintain consistency with binlog_group_commits...
> If not, maybe just have a single status variable, like
> 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
> value (eg. one word of the old value and one word of the new) on 32-bit
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.
> 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).
Daniel Black, Engineer @ Open Query (http://openquery.com.au)
Remote expertise & maintenance for MySQL/MariaDB server environments.