maria-developers team mailing list archive

[Daniel Black <daniel.black@xxxxxxxxxxxxx>]

----- Original Message -----
> Daniel Black <notifications@xxxxxxxxxx> 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/1d5220d1124111f563f9faec355c9343f6e40849

> 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/dd7026a703aabdbe0430bf5f32c6f4f5c6d9c240

> 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/0695fdd9df3501a02ae473c23992345c19342aa8



-- 
-- 
Daniel Black, Engineer @ Open Query (http://openquery.com.au)
Remote expertise & maintenance for MySQL/MariaDB server environments.