From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7656930663 for ; Sat, 1 Jun 2019 05:16:31 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4ofXayE361o for ; Sat, 1 Jun 2019 05:16:31 -0400 (EDT) Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 707623065A for ; Sat, 1 Jun 2019 05:16:30 -0400 (EDT) Received: by smtp33.i.mail.ru with esmtpa (envelope-from ) id 1hX07o-0006ud-8g for tarantool-patches@freelists.org; Sat, 01 Jun 2019 12:16:28 +0300 Date: Sat, 1 Jun 2019 11:44:36 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 10/10] vinyl: get rid of the latch protecting vylog buffer Message-ID: <20190601084436.GH29429@atlas> References: <56d1e35f6d54b87ed8b359af3ddfe4845246dd85.1558103547.git.vdavydov.dev@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56d1e35f6d54b87ed8b359af3ddfe4845246dd85.1558103547.git.vdavydov.dev@gmail.com> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org * Vladimir Davydov [19/05/17 17:54]: > The latch is needed solely to synchronize access to the transaction > write buffer, which is shared by all transactions. We don't need it to > sync vylog readers vs writers as everything is done from the same > thread. So to get rid of the latch, which is a prerequisite for > transactional DDL, as it makes even simply Vinyl DDL operations > yielding, we need to rework the buffer management. > > To achieve that, this patch introduces a separate object for each vylog > transaction, which stores the list of records to be committed. Once a > transaction is ready to be committed, it is sent to the vylog thread, > which writes it to vylog and then wakes up the awaiting fiber. For > non-discardable transactions, it doesn't wakeup any fiber, the fiber > returns immediately and the transaction is freed automatically. > > To allow that, transactions are now allocated on lsregion, which acts > as a queue: new transactions are appended to the tail, committed > transactions are popped from the head. The same could be achieved with xlog savepoints that you introduced earlier, if you allow multiple "savepoints" to be present in xlog tx, each of which could be rolled back independently (the tail of the buffer would have to be moved on rollback). I mean, honestly, if we're getting rid of the latch, there is no point of having adding a separate thread on the way, it just takes a little extra effort. And better yet, we could kill entire vy_log altogether and store everything in xlog. -- Konstantin Osipov, Moscow, Russia