From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (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 7A63F46970E for ; Fri, 31 Jan 2020 11:21:32 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id r19so6213019ljg.3 for ; Fri, 31 Jan 2020 00:21:32 -0800 (PST) Date: Fri, 31 Jan 2020 11:21:30 +0300 From: Konstantin Osipov Message-ID: <20200131082130.GC10740@atlas> References: <45d9f491f91d93c8835ca725c234f7113c0d2aa8.1579541242.git.i.kosarev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45d9f491f91d93c8835ca725c234f7113c0d2aa8.1579541242.git.i.kosarev@tarantool.org> 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/01/20 21:18]: > Trying to perform space:truncate() and space:delete() while reaching > memtx_memory limit we could experience slab allocator failure. This > behavior seems to be quite surprising for users. Now we are allowing > to overuse memtx quota if needed for truncation or deletion, using flag > in struct quota. After performing truncation or deletion we reset the > flag so that quota can be overused any more. This is duplicating the tech already existing with reserved extents. Why not use the reserved extents instead? Why do you need to turn quota completely on/off? -- Konstantin Osipov, Moscow, Russia