>> 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.
>
>Yes. But the way you say it sounds negative. Are you suggesting
>not implementing this feature and just hacking in quota bypass is
>better? Why?
I am afraid that ‘reserving’ approach both doesn’t always guarantee
successful truncation (without some overcomplicated actions) and adds
extra code complexity comparing to the quota on/off mechansm.
I see that simple quota hacking doesn’t look good, but i think it might
be even worse to implement partial solution along with all the extra
code. So far it might be better not to touch this problem, as Vlad
suggests, considering it as not critical.
  
>> However, after that we will encounter the necessity to calculate
>> how much space we need to reserve for truncation tuples.
>
>No. 1 slab is enough.
>
>> 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.
>
>Indeed, this would be strange.
>
>> 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.
>
>Two events can't happen at the same time in a single-threaded
>application. Please take time to explain what you mean here.
I mean «when» in terms of place (where we reserve), not time. I mean
this is one more problem which can't be solved using 'reserve' tech,
although i am not sure it really should be solved through quota bypass.

>--
>Konstantin Osipov, Moscow, Russia 
 
 
--
Ilya Kosarev