From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 26 Nov 2018 23:19:31 +0300 From: Vladimir Davydov Subject: Re: [PATCH 5/6] wal: separate checkpoint and flush paths Message-ID: <20181126201931.o5tntrxgrqsao5uc@esperanza> References: <5ba6de6392cadfc93d0399de4a56c4401317b035.1543152574.git.vdavydov.dev@gmail.com> <20181126175834.GF7839@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181126175834.GF7839@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Mon, Nov 26, 2018 at 08:58:34PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/11/26 10:27]: > > Currently, wal_checkpoint() is used for two purposes. First, to make a > > checkpoint (rotate = true). Second, to flush all pending WAL requests > > (rotate = false). Since checkpointing has to fail if cascading rollback > > is in progress so does flushing. This is confusing. Let's separate the > > two paths. > > 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. > > 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).