

<HTML><BODY><p>Ok, as far as wal_begin_checkpoint does pretty much the same thing as<br>wal_sync and allows us to obtain vclock in a more direct way, i see why<br>we should prefer it. Although it brings slight overhead comparing to<br>wal_sync, it doesn't really seem to be significant. Sent v2 of the patch.</p><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">

        Понедельник, 28 октября 2019, 9:43 +03:00 от Konstantin Osipov <kostja.osipov@gmail.com>:<br>

        <br>

        <div id="">


<div class="js-helper js-readmsg-msg">

        <style type="text/css"></style>

        <div>

                
            <div id="style_15722450051559331824_BODY">* Ilya Kosarev <<a href="mailto:i.kosarev@tarantool.org">i.kosarev@tarantool.org</a>> [19/10/28 09:41]:<br>

> The idea of the patch "relay: join new replicas off read view"<br>

> (6332aca655ae7f95d391bdc0109e79915f6e6ad0), which brought us to the<br>

> currently discussed patch, was to get rid of checkpoint as a prerequisite<br>

> of replica joining. Therefore, why would we need to perform checkpointing<br>

> here and how is it better than proposed approach, which seems to be more<br>

> lightweight?<br>

<br>

wel_begin_checkpoint() doesn't perform a checkpoint. It ensures<br>

the current state of the database is flushed to the write ahead log.<br>

<br>

I don't suggest a full blown checkpoint is initiated. <br>

<br>

<br>

-- <br>

Konstantin Osipov, Moscow, Russia<br>

<br>

</div>

            
        </div>


</div>


</div>

</blockquote>

<br>

<br>-- <br>Ilya Kosarev<br></BODY></HTML>