Re: [tarantool-patches] Re: [PATCH v5 3/3] box: introduce func_index

[Vladimir Davydov <vdavydov.dev@gmail.com>]

On Fri, Jul 26, 2019 at 10:31:30PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [19/07/26 13:14]:
> > On Fri, Jul 26, 2019 at 12:57:43PM +0300, Konstantin Osipov wrote:
> > > * Vladimir Davydov <vdavydov.dev@gmail.com> [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.