From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id F39AF6EC71; Sat, 27 Feb 2021 16:27:09 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org F39AF6EC71 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1614432430; bh=AIfoBGvsSMuQJv/88RNC08W3xLjO9bih36yVXs/oUko=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Y1nJqua5sgPyOoK5kVIWLQp2Gj+Hwlhg4WNpA8+5JJ5dmhzFpsZBMrGj4HDzHcjqX rp1FCaerEJ0MACAFdfLmmBIZq1ehJ7ySe2KYGfIYXJTrTCWWkWV9TB1ZYcc/V3XCkA 1QbkzX8INJz5L7vF9gWB5wPcK0Kjykry1SHpv8rs= Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C14EF6EC71 for ; Sat, 27 Feb 2021 16:27:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C14EF6EC71 Received: by mail-lj1-f182.google.com with SMTP id p15so4950311ljc.13 for ; Sat, 27 Feb 2021 05:27:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=ysAKggE20tBBo7yxAnn6KWm267WxFdx9Q3eQEkhrEVU=; b=lrdIDiS/avlHcuBqqSeENsoA2qEQ3oPjeUIkkTZD33tqWjhVZE2HqIGEBWiHY8EMtl MaTp87vzxNWZI112OSptKBp7tjcGqxoslyYq4hYMxezQnsSOUoMh30zFnUKu3O0uMiFa keVGaqfdHWNW1oGJyp/jIv1pev5PYMy/vvAEDaLMux/lO5UlzsmrMgCwu5szH5W7G8ye 4vMRG3i8VK0OE4uKW/LXr+zutG1vfMO7CMuQp7NgAGf6dLad+lYJ13w//apvqKK2wbvL npzQ8R4zVa68G5QajdufTBAK0H3R2PX3mK4qAJYB102gXXa+yqtQUD4XMtrvgdkGN97z 3Eiw== X-Gm-Message-State: AOAM532z7/o9sUn6rTAYkjBL35YE4A2vg6DdwVtLvjB2ZSzvlJUsEbPY Rkj74RlO9Zz7aVD4pTwuq1en7jzn/Q== X-Google-Smtp-Source: ABdhPJyRq1GyW0y4GCK9SS7bza0wnvAms2id+iyVvUjAl8yXeQvE7d8iz18VeHnyv2ULVljlsB7GMA== X-Received: by 2002:a2e:910d:: with SMTP id m13mr4287645ljg.189.1614432428073; Sat, 27 Feb 2021 05:27:08 -0800 (PST) Received: from sterling.local ([81.25.56.224]) by smtp.gmail.com with ESMTPSA id t2sm1801085ljo.9.2021.02.27.05.27.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Feb 2021 05:27:07 -0800 (PST) Received: by sterling.local (Postfix, from userid 1000) id 30E6EE60067; Sat, 27 Feb 2021 16:27:06 +0300 (MSK) Date: Sat, 27 Feb 2021 16:27:06 +0300 To: Vladislav Shpilevoy Message-ID: <20210227132706.GA104570@starling> Mail-Followup-To: Konstantin Osipov , Vladislav Shpilevoy , Serge Petrenko , gorcunov@gmail.com, tarantool-patches@dev.tarantool.org References: <20210224193549.70017-1-sergepetrenko@tarantool.org> <20210225130514.GB18388@starling> <20210226071829.GD18388@starling> <8a6c0d7e-2231-510c-788d-daa9644f5e84@tarantool.org> <20210226212034.GE84448@starling> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v3] wal: introduce limits on simultaneous writes X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Konstantin Osipov via Tarantool-patches Reply-To: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" * Vladislav Shpilevoy [21/02/27 16:22]: > On 26.02.2021 22:20, Konstantin Osipov wrote: > > * Vladislav Shpilevoy [21/02/26 23:24]: > >> Talking of the other limits - firstly we need to find if some of them > >> really overflows. Then yes, such a semaphone-thing could be applied > >> there too. But AFAIK, there are no other known similar bugs yet. > > > > Exploring this rather theoretically, since there are no user async > > transactions yet, I can imagine such transaction takes up memory > > and then blocks on WAL semaphore. If there is no limit on the > > number of async transactions, it can be a lot of memory. On the > > other hand this can be limited by a yet another semaphore. > > Yes, such transactions will only occupy memory. But the plan is return > an error from box.commit({is_async}) if the WAL queue is full already. > Because we don't want to block the async commit in anyway. Better bail > out earlier and give the user a chance to call normal box.commit() if > necessary. Or introduce some kind of 'try_async' to block if the queue > is full, but no block if not full, I don't know. We didn't think on the > API yet. There is no point in doing parasitic work in this case - performing a transaction and then rolling it back. > -- Konstantin Osipov, Moscow, Russia