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 7719B6EC5A; Sat, 27 Feb 2021 00:20:37 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 7719B6EC5A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1614374437; bh=C0RNHzHuHOCXya2cipQ/NxrMGSWgLqwVN4R8S0i758s=; 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=mYRIPYxs2tDl4y6AA6yIrPSPIhEZQFQPc1HGEPP2WnxJNpxP0q16QeAIJULnGo0yh haW8nPcbEBVs9XSm9wFxQTpdWgV8Up1r/3t2aMWHstfOqnRZYVeagjXT9ZnnQ/Zbi6 n8L+RqiWh8M4fxsUZFJaTSB65BFdaSFOHBZRSh1k= Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (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 2A2716EC5A for ; Sat, 27 Feb 2021 00:20:37 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 2A2716EC5A Received: by mail-lf1-f41.google.com with SMTP id d24so15885306lfs.8 for ; Fri, 26 Feb 2021 13:20:37 -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=i1UyGjg2sfb68tKttD0KShsSupYtDJFsECPKahOMZiQ=; b=F4XIzygWWV7rczNlnxGPLZL+9nnqXBvrnpALXiFfnirnzTl1D4kR/qm8ukKy9mVIe+ ijXjer9RiAXK/IEaEJ/kspCPcqDO5BfETaz+GDyvVxSd0NIqB37s6/Yp/N2ivMYKR8eI WgmR+jOz+GuoPMGEdxIGjYW3L1QtzRImgMA+BRXej2fNCckJBZRXy4zmMkeKReVuOxtP rDhiR+KYvr6xp2Pi2eZTdZBEM4KUupZ7QvHRXVqEy3Xy1EmWCxWW5hIMm/jgtG5RTLUf 3lw+KDXsz0YN60axDxn79dKhFy8tfTcVti+6EkQ7aH/yTYsgT9lz/lV4FvLG0M9aw8Pp eb9g== X-Gm-Message-State: AOAM531wng+8ZwcSVpiPXC/WEAuGuBTSVquWxZqAmylyV2aUifYZMo75 ec9dqWWnEATaa1TGYYjtZrdXydXfVw== X-Google-Smtp-Source: ABdhPJxDjqWKxlRoG785HMubUgMCT70LOGZX5MAC4qW/uzupdxfrLdRa2syroLZQauWJqtWEXJOZ1A== X-Received: by 2002:a19:7402:: with SMTP id v2mr2769681lfe.58.1614374436452; Fri, 26 Feb 2021 13:20:36 -0800 (PST) Received: from sterling.local ([81.25.56.224]) by smtp.gmail.com with ESMTPSA id m30sm1542951ljb.85.2021.02.26.13.20.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Feb 2021 13:20:36 -0800 (PST) Received: by sterling.local (Postfix, from userid 1000) id 043C5E60067; Sat, 27 Feb 2021 00:20:35 +0300 (MSK) Date: Sat, 27 Feb 2021 00:20:34 +0300 To: Vladislav Shpilevoy Message-ID: <20210226212034.GE84448@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a6c0d7e-2231-510c-788d-daa9644f5e84@tarantool.org> 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/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. > >>> Otherwise your overflow will just spill out someplace else. > >> > >> On the contrary. Your proposal to do it in the applier would lead to > >> queue overflow in some other place - in userspace. When the queue is > >> for the entire WAL, it won't overflow. > > > > I did not say it should be in the applier. > > It was a misunderstanding. -- Konstantin Osipov, Moscow, Russia