maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #12027
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
Yes, Sergei, you are right, it works fine!
Additionally, I see now that I implement something very similar to what
Sachin does -- i.e., cloning handler.
I think that we can share one handler among all similar stuff, when we need
to make cascade index searches. But some refactoring is required --
TABLE::clone_handler_for_update is not actually "for update" but rather for
read, and I think it's better to store the handler in parent handler (as
well as clone function), and to call it smth like `internal_handler` (I
call it now check_overlaps_handler, and Sachin calls it update_handler).
Sergei, Sachin, agree?
On Tue, 17 Dec 2019 at 03:50, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> Hi, Nikita!
>
> On Dec 17, Nikita Malyavin wrote:
> > It is used in innodb's implementation of handler::position, to copy the
> key
> > from the record buffer, which is also used to be record[0]
>
> Okay.
>
> It seems that position() was always called with record[0] as an
> argument.
>
> But check_duplicate_long_entry_key() uses store_record()/restore_record()
> to call position(record[0]). Please see if you can remove them now.
>
> > On Tue, 17 Dec 2019 at 01:20, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> > > Hi, Nikita!
> > > On Dec 06, Nikita Malyavin wrote:
> > > > Hi Sergei!
> > > >
> > > > I traced out the problem I faced with refs comparison -- It's in
> > > > key_copy implementation, which uses field->get_key_image, which in
> > > > turn copied data to the buffer passed, but from `field->ptr`. The
> > > > latter is important -- it means, current key_copy implementation
> > > > always copies data from table->record[0].
> > >
> > > I see. It looks like so far all usages of key_copy() used record[0]
> > > indeed.
> > >
> > > But as far as I can see, you're also using key_copy() with
> > > record[0], so why would you need that fix?
> > >
> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and security@xxxxxxxxxxx
>
--
Yours truly,
Nikita Malyavin
Follow ups
References
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Nikita Malyavin, 2019-12-03
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Sergei Golubchik, 2019-12-03
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Nikita Malyavin, 2019-12-03
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Sergei Golubchik, 2019-12-03
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Nikita Malyavin, 2019-12-04
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Nikita Malyavin, 2019-12-04
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Sergei Golubchik, 2019-12-04
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Nikita Malyavin, 2019-12-06
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Sergei Golubchik, 2019-12-16
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Nikita Malyavin, 2019-12-16
-
Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS
From: Sergei Golubchik, 2019-12-16