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 D48316D3F5; Sat, 23 Oct 2021 01:03:14 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D48316D3F5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1634940195; bh=B2jYr9eTVUHaHt/m5cAnahhlL1yRaQ3xlaSLKtfL1TQ=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=prCySk+dEGkPBghWAn3h12ILrEHW04cYw9EuU1W9jk5PKmFdXyt4oUipPvCEm2Z4b ddohkZOnJkXwkCnQLB+K7tuMhwf0CdyDv67MrMF6Xnp95pnvVKirPIIBk+4+V6zN1E F+y3MxlDsYNnselHmk0xjh165bVZUIsaXIqwj2AU= Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (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 EA56D6D3F5 for ; Sat, 23 Oct 2021 01:03:09 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EA56D6D3F5 Received: by mail-lj1-f175.google.com with SMTP id o11so4657788ljg.10 for ; Fri, 22 Oct 2021 15:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=m4O/tiXpB6a0gudOts9ktUPBIleQsKvpXdfUtLZjKbM=; b=c0QMCAm0VbpmAUUAuVeLsQGEaj8e4GC3aTvSCljnCJu8knV5TSn049JRPEwVOAX100 PvU6zGaVh7pE0APNJDqOuk5IJl7V28SUM1jiGH8UtEcJtUNr346FiBsK36lI0X9CrErw 8kNjiH+ncVlrUsZfvO8gUAFMxyAZo5T6UXIAQa/8/w6hTImCvy3kvSumJV9tXsZi+TR5 ggBfX9BM5Bd+YRKUm6KWoAztj11sh56KYrw7XZSlVbsckotVrKUftdk1kR/ixmZEqd5P 9kYe2ISBmMwFZ3V2+XarMUqYPwhZYQ4FI+a1fDSa0KwC7v0fEf3mxQ/+Yy3fwdt5GUA1 e2nw== X-Gm-Message-State: AOAM531eOEnNcEXhubXpu0Ph3v3pV9s4sKubXKUo9EbPIzbbhK84Gbjq W4++iWT8vbm51nVoR59BKerLA1+X/qTgkw== X-Google-Smtp-Source: ABdhPJytrzhrW1Nrv7Yz4x+8oEM57RWat2H4tPCMR2zfDua36JIz1H83qakHm3ul78N/wGTbBxMKLg== X-Received: by 2002:a2e:9e42:: with SMTP id g2mr2507023ljk.483.1634940188710; Fri, 22 Oct 2021 15:03:08 -0700 (PDT) Received: from grain.localdomain ([5.18.251.97]) by smtp.gmail.com with ESMTPSA id f25sm1008918ljp.128.2021.10.22.15.03.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Oct 2021 15:03:07 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id AE2245A0020; Sat, 23 Oct 2021 01:03:06 +0300 (MSK) Date: Sat, 23 Oct 2021 01:03:06 +0300 To: Vladislav Shpilevoy Cc: tml Message-ID: References: <20211014215622.49732-1-gorcunov@gmail.com> <20211014215622.49732-4-gorcunov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH v23 3/3] test: add gh-6036-qsync-order test 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 Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Fri, Oct 22, 2021 at 12:06:09AM +0200, Vladislav Shpilevoy wrote: > > + | ... > > +test_run:wait_cond(function() return box.error.injection.get("ERRINJ_WAL_WRITE_COUNT") > write_cnt end) > > Sorry, keep the code inside of 80 symbols line width. OK > > I added this diff and all the tests passed. That means the only > tested parts of the patchset are apply_synchro_row() and > txn_limbo_is_replica_outdated(). > Without the rest of locking the overall picture becomes incomplete, we introduce the first part of split brain detection. And in second part we'are about to introduce filtering into begin()/commit() pair. > Please, lets try not to submit more untested code. It is enough that > we already have one ticket which simply adds assert(false) into a few > places and the tests pass. It does not make the code better, it just > adds more uncertainty how it works and whether it works at all. This is the correct way to guard access to some particular data to me. In this case we're guarding @promote_term_map and @promote_greatest_term. What you propose is to guard them in "some path" but leave untouched for all others. So the person which would read this code after some years gonna be scratching a head trying to figure out why sometimes access to these members is done locked and somtimes are not. I completely disagree here. Either we lock all accesses either not, not partial lockings please.