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 E6BA06FC8F; Sun, 12 Sep 2021 18:43:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E6BA06FC8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1631461433; bh=6i5Lc6i/Magny92/8WcunQOb3HoZ7+CX4pZvXu0NtCM=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Vqgeh2Dz9idHy+9ish+0vFhSk8eYnj3NPzo7F/kV5DQU5auMwTr2bkkttrmASjvau zLaXmf0e1GVLPlDv7F9G5znMuMupTTBeRFvlEaRfUjwn4jb65tLZ+ojNdFMCi1bNMV IQbo05U0AALqwVYb4TurwMECelAGouB+g9SqZAAI= Received: from smtpng3.i.mail.ru (smtpng3.i.mail.ru [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 982566FC8F for ; Sun, 12 Sep 2021 18:43:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 982566FC8F Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1mPRe1-0006ZC-Mz; Sun, 12 Sep 2021 18:43:50 +0300 To: Cyrill Gorcunov , tml References: <20210910152910.607398-1-gorcunov@gmail.com> Message-ID: Date: Sun, 12 Sep 2021 17:43:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210910152910.607398-1-gorcunov@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD91AE02D33A9C88A2FF3F790D2CFB1565D68082CE688654CB400894C459B0CD1B97B461AA589E1A7623CDDF1729A940AC506C63B2D39B5180C7F7399A604DAC192 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7D77100FFB2844417EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637051ADBC467AF48EA8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D87421303A8D970BFC77BEBA92262FD647117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC2EE5AD8F952D28FBA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18CB629EEF1311BF91D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6A1DCCEB63E2F10FB089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A58496E6A5F2E21EACA0DFF04E16446EFB4EFDB48709BF6985D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA756665624D6DDF07B5410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34A503FBFE8BE8FC4905387D5A4ADDA10CDC96801F004D4AFDF25B3551DACC039565EE13C7880407A01D7E09C32AA3244CDBCDF9DAB744AC73B7F4481F226AD6DC8580396430872480729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojuaewUBhMl4yB8lUlQei86A== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D0BC92C25CFE2ED168E14E4F4166CD0CD3841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v14 0/6] qsync: implement packets filtering 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: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi! Thanks for the fixes! On 10.09.2021 17:29, Cyrill Gorcunov via Tarantool-patches wrote: > Guys, take a look please, once time permit. The questionable moments: > > - use filter disabling procedure for join/recovery: we make it so since > snapshot has promote record which fills initial limbo state I still don't understand why do you need the disabling. Before the snapshot is recovered, the limbo is empty and not owner by anybody. It is fully valid and working, like if DEMOTE is called. Correct? Snapshot's promote should make it belong to the owner persisted in promote. Also correct? The next rows just replay already applied data. Also correct? It managed to apply first time and must manage to do so again. Agree? In what of these statements I miss a mistake which makes you disable the filtering? > - need more tests to cover all possible scenarios > > - I keep filter_confirm_rollback() as is but rereading Vlad's comment > > > > 9. What if rollback is for LSN > limbo's last LSN? It > > also means nothing to do. The same for confirm LSN < limbo's > > first LSN. > > > I presume I need to traverse limbo and test if incoming LSN is > present inside current queue. It should be enough to know the LSN range in there AFAIU. Additionally, I tried the test from the ticket again. It still does not behave as expected. I remind, on the last review I also tried: On top of the branch I tried the test I pasted in the ticket's description. I see the connection now breaks in one direction. But the new leader still follows the old leader somewhy. And you said: I'll take more precise look, thanks! https://lists.tarantool.org/tarantool-patches/YRBUww6p1dUNL0mx@grain/ So what are the news on that? The new leader should not follow the old one. If anything, even the vice-versa situation would be fine I suppose - the old one following the new one. But the current way does not look valid. The old leader could send all kinds of irrelevant garbage and the new leader would happily swallow it. The same happens in this test (on top of the last commit of this patchset): https://github.com/tarantool/tarantool/issues/5295#issuecomment-912106680 The new leader still replicates from the old broken one.