maria-developers team mailing list archive
Mailing list archive
Re: 14c2f90ad08: Idempotent INSERT events for system versioning
On Wed, Mar 13, 2019 at 9:48 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> Hi, Aleksey!
> On Mar 13, Aleksey Midenkov wrote:
> > On Wed, Mar 13, 2019 at 9:01 PM Sergei Golubchik <serg@xxxxxxxxxxx>
> > > 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);
> Chief Architect MariaDB
> and security@xxxxxxxxxxx
All the best,