Re: [PATCH 5/6] wal: separate checkpoint and flush paths

[Konstantin Osipov <kostja.osipov@gmail.com>]

* Vladimir Davydov <vdavydov.dev@gmail.com> [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