From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id EC3F546970E for ; Mon, 10 Feb 2020 13:50:12 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id y6so6608751lji.0 for ; Mon, 10 Feb 2020 02:50:12 -0800 (PST) Date: Mon, 10 Feb 2020 13:50:11 +0300 From: Konstantin Osipov Message-ID: <20200210105011.GA10543@atlas> References: <1581323070.966721067@f426.i.mail.ru> <20200210094924.GA920@atlas> <1581331417.252669431@f523.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1581331417.252669431@f523.i.mail.ru> Subject: Re: [Tarantool-patches] [PATCH v3 2/2] memtx: allow quota overuse for truncation and deletion List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ilya Kosarev Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Ilya Kosarev [20/02/10 13:44]: Ilya, please explain the issues in specific terms: references to source code, test conditions, and so on. I don't see any issue with reserving a slab at Tarantool start for out-of-memory truncate. I don't see any issues with deletes, because deletes are not supposed to use this slab, it should only hold truncate record. Deletes do not allocate tuples anyway. I think you should try to do it and send a patch when you get stuck. You can't expect me to explain how to do it because I don't know what you don't know. -- Konstantin Osipov, Moscow, Russia