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 EE9AD469710 for ; Thu, 4 Jun 2020 23:23:11 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id m18so8948616ljo.5 for ; Thu, 04 Jun 2020 13:23:11 -0700 (PDT) Date: Thu, 4 Jun 2020 23:23:09 +0300 From: Konstantin Osipov Message-ID: <20200604202309.GA146885@atlas> References: <7407b62139349ee3904a674490a6222b0c960a1c.1591292549.git.korablev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7407b62139349ee3904a674490a6222b0c960a1c.1591292549.git.korablev@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] vinyl: rotate mem during index build on demand List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Nikita Pettik [20/06/04 20:49]: > Meanwhile in 17f6af7dc the similar problem has been fixed, still it may > appear that in-memory level of secondary index being constructed has > lagging memory generation (in other words, it's values is less than > the value of current global generation). Such situation can be achieved > if yield which is required to check uniqueness of value being inserted > is too long. In this time gap other space may trigger dump process > bumping global memory generation counter, but dump itself is still not > yet scheduled. It's hard for me to understand this comment, perhaps you discussed the problem verbally, but I'm a bit out of context. Could you write it using an event diagram, something like: user1 user2 vy_scheduler insert ... create_index() yield dump ??? -- Konstantin Osipov, Moscow, Russia