From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtp3.mail.ru (smtp3.mail.ru [94.100.179.58])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id F269D4429E1
 for <tarantool-patches@dev.tarantool.org>;
 Mon, 15 Jun 2020 16:54:59 +0300 (MSK)
Date: Mon, 15 Jun 2020 13:54:58 +0000
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20200615135458.GA5239@tarantool.org>
References: <7407b62139349ee3904a674490a6222b0c960a1c.1591292549.git.korablev@tarantool.org>
 <b3d1965c-dd2b-b37b-d7f5-58c4c4c542f0@tarantool.org>
 <20200609223458.GA11347@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200609223458.GA11347@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH] vinyl: rotate mem during index
 build on demand
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

On 09 Jun 22:34, Nikita Pettik wrote:
> On 07 Jun 17:51, Vladislav Shpilevoy wrote:
> 
> > I checked all the other similar places and propose you to take
> > a look at some of them too:
> > 
> > - vy_build_recover_stmt() calls vy_build_insert_stmt() without
> >   checking mem generation and rotation;
> 
> Во время рекавери ротации памяти не могут происходить..
> vy_point_lookup() может, конечно, илдить, но дампов быть не может.
> Вот коммент в vinyl_engine_begin_initial_recovery() подтверждающий это:
> 
> 		 * We can't schedule any background tasks until
> 		 * local recovery is complete, because they would
> 		 * disrupt yet to be recovered data stored on disk.
> 		 * So we don't start the scheduler fiber or enable
> 		 * memory limit until then.
> 		 *
> 		 * This is OK, because during recovery an instance
> 		 * can't consume more memory than it used before
> 		 * restart and hence memory dumps are not necessary.
> 
> > - vy_squash_process() calls vy_lsm_set() without these actions;
> 
> В теории потенциально тут такая ситуация может произойти (так как сквош
> происходит в отдельном файбере), но там выделяется память всего под один
> тапл (в отличие от построения вторичного индекса, где lsregion_alloc
> зовется для каждого тапла) и поймать такую ситуацию на практике,
> наверное, очень маловероятно.
> 
> > - vy_lsm_commit_upsert() calls vy_lsm_set, ditto.
> 
> Тут тоже в принципе реально: между engine_prepare() и engine_commit()
> есть илд. При этом дамп может стригериться в конце vinyl_engine_prepare()
> (хотя и в vy_tx_prepare() есть ротация). Для этого случая сценарий
> придумать будет проще.
> 
> В любом случае, это я уже отдельными патчами пошлю.
>

По мотивам открыл тикет: https://github.com/tarantool/tarantool/issues/5080