As far as i see, memtx reserves extents using specific pool and
mempool_alloc. We will need to implement additional feature to reserve
slabs in memtx arena and provide them specifically for truncation
needs. However, after that we will encounter the necessity to calculate
how much space we need to reserve for truncation tuples. I guess we
might want to reserve a truncation buf for each created space and
re-reserve it on each truncation, although such logic seems
overcomplicated.
Furthermore, the problem with space:delete() might happen exactly when
we are trying to reserve a slab to guarantee successful statement-level
rollback. This can't be fixed using reservation tech.
Четверг, 6 февраля 2020, 19:26 +03:00 от Konstantin Osipov <kostja.osipov@gmail.com>:
 
* Ilya Kosarev <i.kosarev@tarantool.org> [20/02/06 19:15]:
>
> From memtx_tuple_new() we call smalloc(). In case it is calling
> mempool_alloc(), we are passing the pool from memtx->alloc, chosen
> depending on it's size. Later this tuple may be deleted. Then smfree()
> is called, which uses mempool_find() to acquire the pool we want to
> free.
> In case we are using some other specific pool, current mempool_find()
> won't be able to find it. This means we need to process this case
> explicitly and it seems to add noticeable unjustified complexity to the
> code.

Why do you need to use a special pool? Can't you reserve a single
slab in memtx_arena, just like memtx reserves extents now, and
allow use of this slab for any pool *only* when processing truncate?

--
Konstantin Osipov, Moscow, Russia
https://scylladb.com
 
 
--
Ilya Kosarev