Hi, Aleksey! On Mar 13, Aleksey Midenkov wrote: > > > > Query_log_event() can already store microseconds, see Q_HRNOW flag. > > So better to add them to Rows_log_event, if needed. > > > > But I don't quite understand why it's needed. > > In scope of MDEV-16370 slave adds history record. Master sends UPDATE > of row (row_start = X.Y; row_end = MAX). Query time is X.(Y + n). > > Slave adds history record and gets timestamp: X from master; F from > system time fractions. If F < Y this makes bad history record > (row_start = X.Y; row_end = X.F).
That's exactly what I wrote below. You can make F=Y, because the event already contains Y, you won't need to extend it. > > What you see - microseconds from the system time and seconds from > > the binlog event - is a workaround for replicating non-versioned > > master to versioned slave, where binlog events don't have > > microseconds. > > > > In your case versioned-to-versioned RBR, row events should have > > microsecond-exact timestamps already, you can get them from there. > > > > Only Delete_rows_log_event might not have the actual timestamp(6), > > but this can be fixed on the master, I suspect. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
