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 : >  >* 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