From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Wed, 28 Nov 2018 19:46:55 +0300 From: Konstantin Osipov Subject: Re: [PATCH 5/6] wal: separate checkpoint and flush paths Message-ID: <20181128164655.GA20801@chai> References: <5ba6de6392cadfc93d0399de4a56c4401317b035.1543152574.git.vdavydov.dev@gmail.com> <20181126175834.GF7839@chai> <20181126201931.o5tntrxgrqsao5uc@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181126201931.o5tntrxgrqsao5uc@esperanza> To: Vladimir Davydov Cc: tarantool-patches@freelists.org List-ID: * Vladimir Davydov [18/11/26 23:21]: > > I agree with the two paths, but wal_flush() as a name is > > confusing, since no flushing is happening. > > This function makes sure that all requests submitted to WAL are > processed before it returns, i.e. it effectively flushes WAL cpipe. > Its name is consistent with cbus_flush, which it uses under the hood. WAL is a disk object, not a memory object, so flush can be easily confused with flushing all memory to disk. > > Let's call it wal_sync() or wal_wait() or something similar. > > > > wal_checkpoint() could also be made more obvious and renamed to > > wal_rotate(). > > There will be more to WAL checkpointing than simply rotating the current > WAL file. For example, in patch #6 I update WAL's vision of the last > checkpoint vclock there, and in the scope of checkpoint_wal_threshold > option implementation I will reset the size of WAL files written since > the last checkpoint there, too. In fact, I'll need two functions to do > all those things properly - one to be called when checkpointing is > started (this is where wal_checkpoint() is currently called), another - > when it completes. I'm planning to call them wal_begin_checkpoint() and > wal_commit_checkpoint() to match the corresponding engine methods (again > see patch #6). OK. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov