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 575ED6FC87; Fri, 1 Oct 2021 15:37:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 575ED6FC87 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1633091841; bh=MzIUu7D9dOYLjAHGH0nh1nEHg9s+KPPgpE/fvi0xEq8=; 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=hp6eyuJ9oUJgoPBzkARIk9ALocJyp8R83LyUb7jcfc2xoPDGBnZicN5LY7YUYar5D b+nLqNO6ZsUys1iz1OssqVAhneC4wlm54iIsn/Tda2B7CSyypZ5QHuaf0+hQaqJEtd nlo9lT9PUGiCFJgUn9YbdTEuIDx13vuqBNN3+Ja4= Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (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 38F5B6FC87 for ; Fri, 1 Oct 2021 15:37:19 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 38F5B6FC87 Received: by smtp53.i.mail.ru with esmtpa (envelope-from ) id 1mWHmw-0003gf-Lc; Fri, 01 Oct 2021 15:37:18 +0300 To: Cyrill Gorcunov Cc: tml , Vladislav Shpilevoy References: <20210930094445.316694-1-gorcunov@gmail.com> <20210930094445.316694-3-gorcunov@gmail.com> <0c64d172-4fa8-29ec-7845-ff772738c09a@tarantool.org> Message-ID: <590f764f-57f1-eeaf-925c-263c29121fd5@tarantool.org> Date: Fri, 1 Oct 2021 15:37:18 +0300 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD96A58C36AA2E99649E150573C3DCDB29943BD5C8B56246B79182A05F538085040B9CB508D419355A58A821FFC1F702EB9BCBD07326E1817E3DF65C3DBF32EFEB0 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7CB1634DB9A2F7B99EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637FACF2191C0719DEE8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8A642BF626C2DB7C4E3B690D3702B9B72117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCF1175FABE1C0F9B6A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD1828451B159A507268D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6D635BA3ABDB36C18089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A55DCBE5910D2741E842C0C0AA49523A0D36D7A89706699E06D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA757AF5085B7B0228D6410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3455049D7B43D89D64F06913EEBB6EE8FC3824D4177C9A6F975DC473FFB096E3DD52BF60061CFAEE291D7E09C32AA3244CC9A4B11CA28A538EEE3611FB322CB514A8CE788DE6831205FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojJNmX3owDPmE8hITVOqt9sA== X-Mailru-Sender: 3B9A0136629DC9125D61937A2360A446D5ABFC96E4381C389471A5CEA51048342717EB943137FE5B424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BC112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v19 2/3] qsync: order access to the limbo terms 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: Serge Petrenko via Tarantool-patches Reply-To: Serge Petrenko Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 01.10.2021 15:31, Cyrill Gorcunov пишет: > On Fri, Oct 01, 2021 at 03:14:52PM +0300, Serge Petrenko wrote: > ... >>> +/** Process a synchronous replication request. */ >>> void >>> txn_limbo_process(struct txn_limbo *limbo, const struct synchro_request *req); >> Thanks for the patch! >> >> Mostly ok with one question: >> >> What about txn_limbo_write_confirm/txn_limbo_read_confirm pairs issued >> inside txn_limbo_ack() and txn_limbo_on_parameters_change() ? >> >> Shouldn't they take the latch as well? I mean, txn_limbo_ack() and >> txn_limbo_on_parameters_change() as a whole. > Wait, Serge, currently we guard promote_map/max_term, so it won't be > read while there is its update on the fly. Thus If only I'm not missing > something obvious txn_limbo_on_parameters_change() can't interfere with > promote data or race with it anyhow. If you mean some other race then > it seems I don't see it yet, but I suspect I might be simply wrong :) Shouldn't we guard limbo->owner as well? Otherwise you may start writing confirm for an old leader once promote for a new one is already in progress. I don't remember us discussing this before, so, maybe I'm just confused. -- Serge Petrenko