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@mariadb.org> 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@mariadb.org> 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@mariadb.org
-- Yours truly, Nikita Malyavin