From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (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 95853430D56 for ; Tue, 29 Oct 2019 20:02:21 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id y3so16120876ljj.6 for ; Tue, 29 Oct 2019 10:02:21 -0700 (PDT) Date: Tue, 29 Oct 2019 20:02:19 +0300 From: Konstantin Osipov Message-ID: <20191029170219.GB29443@atlas> References: <20191029142356.5196-1-i.kosarev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191029142356.5196-1-i.kosarev@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3] 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: Ilya Kosarev Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org, tarantool-patches@freelists.org * Ilya Kosarev [19/10/29 19:59]: > join_vclock test could fail on huge load due to vclock advance > comparing to an actual WAL. In order to fix this we updated wal_sync so > that now we can obtain up to date vclock on the flushed state using it. > It is also better to get max index and index count in single request in > join_vclock test. With fixes mentioned above it is not fragile anymore. I suggest we copy vclock. it's not a good idea to make the two threads depend on each other on memory. the relay thread may be cancelled while the messasge is in the wal thread. -- Konstantin Osipov, Moscow, Russia