← Back to team overview

maria-developers team mailing list archive

Re: 6ac19d09c66: MDEV-16978 Application-time periods: WITHOUT OVERLAPS


We've also had MDEV-19082 <https://jira.mariadb.org/browse/MDEV-19082>
-- change
application-time period tables to use HA_EXTRA_REMEMBER_POS.

On Fri, 6 Dec 2019 at 18:33, Nikita Malyavin <nikitamalyavin@xxxxxxxxx>

> 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 have already came across it while implementing FKs, and have fixed the
> implementation in the separate commit (see key_copy: use from_record
> argument to copy the data from). That fixes 'innodb' test combination.
> I think now everything you wanted so far is in the branch, so am waiting
> now for your comments on the new code!
> Kind regards,
> Nikita Malyavin
> On Thu, 5 Dec 2019 at 02:36, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
>> Hi, Nikita!
>> On Dec 05, Nikita Malyavin wrote:
>> > Heh, unfortunately comparing refs will not work in conjunction with
>> >
>> > for innodb ref can be a primary key, if it has it, so index is not
>> > clustered. The index we're evaluating can be different from a primary
>> key.
>> >
>> > In that case some values can be left unfetched with KEYREAD.
>> >
>> > All that is because if innodb has primary key, it just does key_copy
>> In InnoDB every secondary key automatically has primary key at the
>> end, because after finding the key value in a secondary index,
>> InnoDB needs to fetch the corresponding row, so it has to know the PK
>> value for that secondary key.
>> Generalizing, every secondary key has to have the "ref" for the
>> corresponding row. In InnoDB it's PK, in MyISAM it's the row offset, in
>> MEMORY it's pointer. But either way, in any engine, any secondary key
>> knows the ref for the corresponding row.
>> Regards,
>> Sergei
>> VP of MariaDB Server Engineering
>> and security@xxxxxxxxxxx

Yours truly,
Nikita Malyavin