Hi, Aleksey! On Dec 27, Aleksey Midenkov wrote:

...

...

MDEV-15458 Segfault in heap_scan() upon UPDATE after ADD SYSTEM VERSIONING

* HA_EXTRA_REMEMBER_POS, HA_EXTRA_RESTORE_POS for HEAP storage engine * Versioning tests support

As far as I can see, there are two approaches to fixing this bug. And if we go the way of HA_EXTRA_REMEMBER_POS/HA_EXTRA_RESTORE_POS then your fix is good.

But I'd still like to understand whether write_row is supposed to disturb the scan. Why should heap_write() overwrite info->current_ptr=pos and info->current_hash_ptr? Inserting a row doesn't happen at the "current position", so I don't quite understand why it modifies current_ptr at all. There is no functionality like "continue the scan from the last inserted row", right? It just doesn't make sense to me.

I don't know why it works like this, maybe to keep consistency at API level: we insert record and then we able to access it without search. HEAP storage was copypasted from MyISAM where `lastpos` analogy also is updated at mi_write(). Without updating `current_ptr` and `lastpos` tests don't fail (main, funcs_1, heap). But I can't say whether the performance is affected and how it will go in production.

Thanks for the idea. I've tried to fix handler::write_row to not reset the scan. This, indeed, worked. I've also asked Monty and he also was of the opinion that handler::write_row should not reset the scan. I've pushed into a stage tree a fix with your test cases. Let's see how it'll go. Regards, Sergei Chief Architect MariaDB and security@mariadb.org