From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 27 Jul 2019 14:42:48 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH v5 3/3] box: introduce func_index Message-ID: <20190727114248.GB4659@esperanza> References: <25789ea46e8fcec527bd7864209bb6ea2113dca5.1564079799.git.kshcherbatov@tarantool.org> <20190726094958.GA4080@esperanza> <20190726095743.GG9916@atlas> <20190726101032.GB4080@esperanza> <20190726193130.GC14622@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190726193130.GC14622@atlas> To: Konstantin Osipov Cc: tarantool-patches@freelists.org, Kirill Shcherbatov , v.shpilevoy@tarantool.org List-ID: On Fri, Jul 26, 2019 at 10:31:30PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [19/07/26 13:14]: > > On Fri, Jul 26, 2019 at 12:57:43PM +0300, Konstantin Osipov wrote: > > > * Vladimir Davydov [19/07/26 12:54]: > > > > > > > > There's one thing about _func_index space that keeps bothering me: since > > > > insertion of a tuple into this space is a yielding operation and this > > > > operation is executed after insertion of a tuple into _index, we won't > > > > be able to wrap space.create_index() into box.begin/commit, because only > > > > the first DDL statement in a transaction is allowed to be yielding. > > > > > > I think we agreed to solve this to build func index at recovery > > > in _func_index trigger and at create in _func trigger. > > > > I don't understand how it's connected with recovery. Could you please > > elaborate? > > > > Just to be clear, I mean the following: > > > > space.create_index(): > > _index:insert{...} > > _func_index:insert{...} > > > > The latter may yield so we can't use box.begin/commit in > > space.create_index() Lua function. > > It will yield only during recovery. During normal operation I > thought we're going to build the index ad _index:insert{} That's not how things currently work AFAICS. Anyway, this means that we'll have to have some sort of redundancy: func id should be stored both in _func_index and _index system spaces. Besides, we'll invoke different code paths on recovery and during normal operation. I see clearly now that it's by far better than recovering _func space before _index space. Thanks for clarification.