Hi, Aleksey!

On Jan 31, Aleksey Midenkov wrote:
> revision-id: ab6ef429a84 (versioning-1.0.7-2-gab6ef429a84)
> parent(s): 14c2f90ad08
> author: Aleksey Midenkov <midenok@gmail.com>
> committer: Aleksey Midenkov <midenok@gmail.com>
> timestamp: 2018-11-26 12:46:37 +0300
> message:
>
> MDEV-16370 row-based binlog events (updates by primary key) can not be applied multiple times to system versioned tables
>
> Case 2:
>
> * Idempotent BINLOG updates: duplicate key on history row is skipped;
> * Fix row start and warn when applying BINLOG from the past.

As far as I can see now you cannot just arbitrarily adjust row_start.

Think of it in term or application time period tables, a primary key is
(kind of) defined WITHOUT OVERLAPS. There is no explicit constraint, it
happens automatically when the history is valid.

Now, here's your test case:

timestamp=100; insert (1,1)    -> the table has (1,1,100,MAX);
timestamp=300; update to (1,3) -> (1,1,100,300),(1,3,300,MAX);
timestamp=200; update to (1,2) -> here the hisory row should've been (1,3,300,200)
but you adjust it to get

  1,1,100,300
  1,3,199,200
  1,2,200,MAX

and if you select AS OF 199, you'll get two rows for the pk=1

So, let's

* ignore HA_ERR_FOUND_DUPP_KEY (please check if it's needed for insert
  or delete too)
* add TIMESTAMP=xxx to mysqldumps.

can vers_insert_history_row see row_start>row_end in a normal use case?
no replication or any other way of adjusting the timestamp.
equality can surely happen, but greater than ?

Regards,
Sergei
Chief Architect MariaDB
and security@mariadb.org