Hi Sergei! On Thu, Apr 4, 2019 at 8:59 PM Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Aleksey!
On Apr 04, Aleksey Midenkov wrote:
On Thu, Apr 4, 2019 at 5:08 PM Sergei Golubchik <serg@mariadb.org> wrote:
And I didn't want to force the master to include microseconds in every single event for every single user just in case someone would decide to do unversioned->versioned replication.
But is it really an issue: do you know setups where replication communication is a bottleneck?
It's few percent increase of the binlog size. Not much.
And it's a general principle - there will be definitely less than 1% of users, who will use this. Less than 0.1% too. Most probably, less than 0.01%. So, the remaining 99.99% should not pay the price for it.
Btw, it would be good to see the stats. We have some feedback plugin that does the job, don't we?
Yes.
Also, I thought that processing of 1000000 Query_log_event's in a second is not realistic.
Now it fails just with several events. I guess because system_time.sec_part is not reset to 0 initially.
You said yourself that is is reset:
start_time_sec_part= system_time.sec_part= 0;
Initially it's reset in THD::THD() too:
system_time.start.val= system_time.sec= system_time.sec_part= 0;
It is synchronized with hardware clock on each set_start_time().
It must be a bug. Hardware clock shouldn't overwrite the counter as it comes from the slave.
Yes. And there are more complications: for replication log we can check thd->slave_thread, because it is replayed, well, in a slave thread. But executing it from client (which is original MDEV-16370 bug) does not execute it in a slave thread.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
-- All the best, Aleksey Midenkov @midenok