Sergey, On Wed, Mar 13, 2019 at 9:48 PM Sergei Golubchik <s...@mariadb.org> wrote:
> Hi, Aleksey! > > On Mar 13, Aleksey Midenkov wrote: > > On Wed, Mar 13, 2019 at 9:01 PM Sergei Golubchik <s...@mariadb.org> > wrote: > > > 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. > > > > I don't like it for a couple of reasons. It's a hackish way that is > > hard to remember and hard to figure out for unenlightened people. > > What do you mean by that? > It's higher overhead costs in terms of support. > > > It leads to history mismatch between master and slave. > > How it can cause a history mismatch? > Obviously fractions will differ. On master it will be: (row_start = X.Y; row_end = X.(Y + n)); On slave it will be: (row_start = X.Y; row_end = X.(Y + 1)); In case Y = 999 999, it will be: (row_start = X.Y; row_end = (X + 1).0); > Regards, > Sergei > Chief Architect MariaDB > and secur...@mariadb.org > -- All the best, Aleksey Midenkov @midenok
_______________________________________________ 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
