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 8D4BB6EC55; Tue, 13 Jul 2021 00:21:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 8D4BB6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626124881; bh=XoJejy3HbplFvAo05FquOQzKvp8fnOg5ruVcY0lYcMg=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=uxOByVB6lJc8DuaPNXYGTgVw4etuKm9E0Uvu2eKpOaLxGfEP9mt9QgKyjyN8CxdBt 7QVqbqeZ2T+DMN5kYqNOVgYPKe6t24W0Pslx3kH0mLg6Sx23MjD82qI9JI1Odva1gR DKwrTTvZ+jTfQdjz/qPenaJrQyRtOylDap4F2hJ4= 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 304966EC5C for ; Tue, 13 Jul 2021 00:20:23 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 304966EC5C Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1m33Li-0001GX-Jo; Tue, 13 Jul 2021 00:20:22 +0300 To: Cyrill Gorcunov , Serge Petrenko Cc: tml References: <20210710222803.253251-1-gorcunov@gmail.com> <187d1ae2-99cb-50d4-d5b4-18aa6c5f5546@tarantool.org> Message-ID: <4d8f7481-eccf-3d44-fb76-402c4be71414@tarantool.org> Date: Mon, 12 Jul 2021 23:20:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD97BB0EF39AD2B33D52D9CC5C87942E9F1EA2CB6CC9AFB41C2182A05F538085040B388F00C7BCDFA62FD83E0CE9E28E71632E253D3A12CAA5FD0329E51A906F1ED X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7ECD3FEFFF0C7120DC2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7DB84ED444C624799EA1F7E6F0F101C6723150C8DA25C47586E58E00D9D99D84E1BDDB23E98D2D38BBCA57AF85F7723F22F37D0612A9FB0C184B22A0F6C4F603ECC7F00164DA146DAFE8445B8C89999728AA50765F7900637DCE3DBD6F8E38AFD389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC8744B801E316CB65FF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8B08F9A42B2210255C75ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A541667CD0423A21AA8A2E962C58BB544BFFBDEE7E71D649ADD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA759DD14948C6BCD3BA410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34DA1FE609583D493CD536269ADDA674520219BC890B7967620210A508A10349E6913DBA30034D27CF1D7E09C32AA3244C07DC88A0D097CCB876A9EFB61C5EDD87C3B3ADDA61883BB5FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojAZDAgpmGsvaojGb/4x/qxw== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D86EE24D310D550E70C27BE106D2525073841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH] limbo: introduce request processing hooks 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" On 12.07.2021 19:04, Cyrill Gorcunov wrote: > On Mon, Jul 12, 2021 at 07:49:49PM +0300, Serge Petrenko wrote: >>> >>> at this moment the data from applier 2 is actually queued >>> for write as valid but we just wrote the term 3, so if we would >>> had been updating terms map earlier (before jornal write) the data >>> from applier 2 should be NOPified. I think there is some problem >>> because due to journal write lag the data is not as it could be >>> if terms map updated early. Serge, Vlad, am I right? Which consequences >>> can be here? IOW, should not we track terms earlier even without >>> my filter series? >> Looks like a bug, indeed. >> >> We may either introduce a limbo latch or start tracking terms before the >> WAL write. >> >> I'm starting to like the idea with limbo latch more. >> >> It's come up a couple of times already for various occasions, so maybe it's >> time to finally implement it. > > Yeah, I think this fully incorporates into the my filter+apply stages > and I'll address the latching there then. Thanks! Все так, да. Латч должен и сделать твой патч в 200 раз проще, и починить этот баг. Если конечно я не замечаю пока какой-то проблемы скрытой в латче.