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

[Vladimir Davydov <vdavydov.dev@gmail.com>]

On Mon, Nov 26, 2018 at 08:58:34PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [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).