From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 20 May 2019 11:09:53 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH 00/10] vinyl: don't yield in DDL on_commit triggers Message-ID: <20190520080953.oaq7jwi3ib5t5zlv@esperanza> References: <20190518183538.GA9448@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190518183538.GA9448@atlas> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Sat, May 18, 2019 at 09:35:38PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [19/05/17 17:54]: > > DDL on_commit triggers may yield on vylog write, even though they don't > > really need to wait for the transaction to be flushed to disk, as we can > > recover it after restart. This blocks implementation of transactional > > DDL (see #4083), because even an empty index creation may yield and > > hence can't be executed transactionally along with other lightweight > > operations, such as space creation. > > > > This patch reworks vylog implementation so that we don't need to yield > > in case the vylog transaction is non-discardable (i.e. stays in the > > memory buffer in case of failure). Since on_commit triggers issue only > > non-discardable transactions, this makes them non-yielding, as they > > should be. > > why do you need to have an own thread for vylog? Because this simplifies things a lot - we don't need to synchronize between vylog readers and writers as everything is done from the same thread. Currently, we read vylog from coio and write it from WAL using a latch to synchronize between them. This makes any write to vylog, even non-discardable one, which lands in the memory buffer on disk error, yielding. Besides, all those calls from vylog to WAL and back look ugly. Anyway, what was the reason to write vylog on behalf of WAL in the first place?