From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 4 Jul 2019 11:09:09 +0300 From: Konstantin Osipov Subject: Re: [PATCH 6/6] Replace schema lock with fine-grained locking Message-ID: <20190704080909.GB24820@atlas> References: <20190703193541.GH17318@atlas> <20190703195605.dhuoxv7xrxqzklug@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190703195605.dhuoxv7xrxqzklug@esperanza> To: Vladimir Davydov Cc: tarantool-patches@freelists.org List-ID: * Vladimir Davydov [19/07/03 23:00]: > TBO I don't think you follow. It isn't a lock, actually. It's just a > flag saying the space is busy building an index. If someone tries to do > something with a space that is busy, they will fail. This is consistent > with vinyl tx manager behavior. No deadlock is possible by design. It's a kind of locking called optimistic locking. Any lock can be acquired in optimistic mode (_trylock()) and in pessimistic mode. Once you have normal locks you can trylock them ad nausea, the only question is whether users will like it. Imagine I have a DDL script which I use to update/upgrade my data on production. Do I really want to add re-tries to this DDL script now that I know it worked in my test environment? Most users don't. With transactional data dictionary multiple metadata locks are around the corner. Imagine this: box.begin() box.space.foo:rename('tmp') box.space.bar:rename('foo') box.space.foo:rename('bar') box.commit() the same can will soon be possible to do in SQL as well. all these locks will have to stay around till commit, so leave through WAL yield. In other words, we either need to switch the data dictionary to MVCC or to use locks, or better yet, have both mechanisms available so that we can use whichever we need when we need it. -- Konstantin Osipov, Moscow, Russia