From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id E06546EC55; Wed, 16 Jun 2021 16:32:42 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E06546EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1623850363; bh=xeHUjSDltj5MX8GoaBsv8V1U4tu3/xnIXt7AIKVnnSU=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=wiOHHovaanTVY8+CpPLumHLsBmCwEx8qR4tvZyfej5uT2ArOZCzZJrSxgfnCs5HE/ PASKLsXxfD+961V5D1D0/vS2EmT3Mt5Q7j3qoYfcbwdczZYWXut12NsJTFccank2EH jnWX98rguHQMIxuGYMZ/CjUGkl5rgDw8PL4WPh3M= Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C96056EC55 for ; Wed, 16 Jun 2021 16:32:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C96056EC55 Received: by mail-lf1-f45.google.com with SMTP id q20so4412526lfo.2 for ; Wed, 16 Jun 2021 06:32:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Vhv03rKxqs1d7KtkHaygRK0d4sH1CzZjshZnqc0521U=; b=q/M7GncdMSKaQVTTzM+RHZUHTWCRSDCynKHB9hc+V5l05i0hGXy24mWqsjXfcikYqL REXF7X9VROE1AtqdYm2JZ6I3GN8nd+WWEnxV3+PGJnkMAOyXqYyQ6ixq1rFtBxXu1jKm YS6E9pBDJoiMJoMyWcTtHTk2YFaTprXzcQKIYMco2XuD3VQheFjDjGc6FV3jRyCNgS8B UEAHXK92XwvzVgzMrYh0eWfiuqDIn+B3amejG2kC8X1xwyp9boff+2ApYkOQqVUO9qGQ L/4mytKxhgpGuB5vBBYjO3c3xvJCSbuC24z0XvnTThtDGAWrwgqU0r5rM5X4DareUd/B F8bQ== X-Gm-Message-State: AOAM5301hiClz5pcObMi8k7tpn/CJ3uW8uuPRyxgm58wF0JXqW84d6jd X+RnNWHnmxKDYF2E82CEakir7FOOFOo= X-Google-Smtp-Source: ABdhPJwt0MKVJWEnoN45ruNtIY5F3FKpg7CFnH5kwfgv3uQMGrW0ctX5/I+rzB34TpDWyLfzektL6g== X-Received: by 2002:a19:385b:: with SMTP id d27mr3838383lfj.600.1623850360490; Wed, 16 Jun 2021 06:32:40 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id c32sm273708lfv.30.2021.06.16.06.32.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jun 2021 06:32:39 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id C8B8C5A002A; Wed, 16 Jun 2021 16:32:38 +0300 (MSK) Date: Wed, 16 Jun 2021 16:32:38 +0300 To: Serge Petrenko Message-ID: References: <20210607155519.109626-1-gorcunov@gmail.com> <20210607155519.109626-2-gorcunov@gmail.com> <22738ee6-74e1-0090-4eb0-c08183bb16e8@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22738ee6-74e1-0090-4eb0-c08183bb16e8@tarantool.org> User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH v8 1/2] applier: send transaction's first row WAL time in the applier_writer_f X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Cc: Vladislav Shpilevoy , tml Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Tue, Jun 15, 2021 at 12:36:02PM +0300, Serge Petrenko wrote: > > @@ -193,6 +196,16 @@ applier_writer_f(va_list ap) > > applier->has_acks_to_send = false; > > struct xrow_header xrow; > > xrow_encode_vclock(&xrow, &replicaset.vclock); > > + /* > > + * For relay lag statistics we report last > > + * written transaction timestamp in tm field. > > + * > > + * Replica might be dead already so we have to > > + * test on each iteration. > > + */ > > + struct replica *r = replica_by_id(replica_id); > > + if (likely(r != NULL)) > > + xrow.tm = r->applier_txn_start_tm; > > How could a replica be dead here? > AFAIR we delete a replica only when it's deleted from _cluster. Shouldn't > the applier writer be dead as well by that time? Before accessing replica_by_id we're sitting in event loop trying to fetch data from the network. Which means an admin may cleanup the entry manually before we get back to this code in result we will get a nil dereference (if only I'm not missing something).