From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 24E3B430D56 for ; Tue, 29 Oct 2019 00:10:10 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id 139so12734577ljf.1 for ; Mon, 28 Oct 2019 14:10:09 -0700 (PDT) Date: Tue, 29 Oct 2019 00:10:08 +0300 From: Konstantin Osipov Message-ID: <20191028211008.GB11163@atlas> References: <20191028122506.4833-1-i.kosarev@tarantool.org> <9c427c1a-9c6f-263b-8cac-99458ccdc8fd@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9c427c1a-9c6f-263b-8cac-99458ccdc8fd@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2] replication: fix join vclock obtainment in relay_initial_join List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [19/10/29 00:08]: > It looks wrong, that we do begin_checkpoint() but omit > commit_checkpoint(). I would call commit too. Probably now > begin() does not allocate any resources, but it may start > in future, and we will have a leak here. This would be wrong, too. Wal uses commit_checkpoint() as a singal that it can recycle wal logs. This is the code Georgy is moving to GC (but his patch is not in yet). One way to fix it would be to add vclock out parameter to wal_sync(). -- Konstantin Osipov, Moscow, Russia