← Back to team overview

maria-developers team mailing list archive

Re: ab6ef429a84: MDEV-16370 row-based binlog events (updates by primary key) can not be applied multiple times to system versioned tables

 

Hi Sergei!

On Wed, Mar 13, 2019 at 7:16 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Aleksey!
>
> On Jan 31, Aleksey Midenkov wrote:
> > revision-id: ab6ef429a84 (versioning-1.0.7-2-gab6ef429a84)
> > parent(s): 14c2f90ad08
> > author: Aleksey Midenkov <midenok@xxxxxxxxx>
> > committer: Aleksey Midenkov <midenok@xxxxxxxxx>
> > 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.
>

Add SET TIMESTAMP for each versioned record or just single SET TIMESTAMP
per dump? I almost made the former when I realized that you could mean the
latter.


>
> 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 ?
>

I don't know of such cases.


>
> Regards,
> Sergei
> Chief Architect MariaDB
> and security@xxxxxxxxxxx
>


-- 
All the best,

Aleksey Midenkov
@midenok

References