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 DF44C6FC8F; Fri, 16 Apr 2021 12:28:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DF44C6FC8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618565329; bh=uDgr9IU8xv6KmplJz3zLtNcH1mm6x7dcnVS58guB18o=; 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=rSPrP+42+eXRWAx7sZ0U9zprF6JtI6OKZD6tL5Rr24h2RTydjtS4fJj9LNcJVPug7 leU2LIAW1gNDvn3BcuduRssWdyPZX59rwqdLqu1Ybs9di84RQ4wSyGyEu4YbhAnyiv OapQrprKg0ToivYKKnKFkTTIzfI/pUskbXi+Reuc= Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106]) (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 C06D46FC8F for ; Fri, 16 Apr 2021 12:28:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C06D46FC8F Received: by smtp46.i.mail.ru with esmtpa (envelope-from ) id 1lXKmO-0005Tc-0R; Fri, 16 Apr 2021 12:28:48 +0300 To: Vladislav Shpilevoy , gorcunov@gmail.com Cc: tarantool-patches@dev.tarantool.org References: <63f4e63825172aaad50b910ed7c0431246380d45.1618409665.git.sergepetrenko@tarantool.org> Message-ID: <704bbea0-f575-4253-630c-eff5c6a269bd@tarantool.org> Date: Fri, 16 Apr 2021 12:28:47 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E74809299FB6B3996B874F289A033C44AD400182A05F538085040B02F645B939338D89A6F3490C92092EC377917E179E3E638D7B28F0CD5EE6724 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE77EC6B62FF4153F51EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637D51A55327EA515C2EA1F7E6F0F101C67CDEEF6D7F21E0D1D9295C2E9FA3191EE1B59CA4C82EFA6581AAC8F22FFA9F83875B68D505EA8F42BF6B57BC7E64490618DEB871D839B73339E8FC8737B5C2249E5E764EB5D94DBD4CC7F00164DA146DAFE8445B8C89999729449624AB7ADAF37F6B57BC7E64490611E7FA7ABCAF51C92176DF2183F8FC7C000E2D00546020E658941B15DA834481F9449624AB7ADAF37BA3038C0950A5D3613377AFFFEAFD2691661749BA6B9773587047FD9FF236CBA7B076A6E789B0E97A8DF7F3B2552694A1E7802607F20496D49FD398EE364050F9647ADFADE5905B1B1CA5D0BF4193578B3661434B16C20AC78D18283394535A9E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6D0C9BB9AE6BD5D69089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5A09AFD911EDD49F2C74A6ED13383130DD228D3463854114DD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D348BF433665406F390B6767A0B0A0989DC5148D959DDD20A3E616E6695CC50C0B7DE8EB83799ACDBF21D7E09C32AA3244C3DBD9BEAAF680ECB07F21F4F2D9B3CE0A95CA90A1D8AC565FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj3S6P1v0GIqRdIhZVfkYJFA== X-Mailru-Sender: 583F1D7ACE8F49BDD2846D59FC20E9F81575E0C7E5462CE7B344AA2990C81C6E93404BA5F9DF91C1424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BC112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v3 04/10] box: make clear_synchro_queue() write a PROMOTE entry instead of CONFIRM + ROLLBACK 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" 16.04.2021 02:20, Vladislav Shpilevoy пишет: > Thanks for working on this! > > See 2 comments below. > >> diff --git a/src/box/box.cc b/src/box/box.cc >> index 70b325180..9adb6ba46 100644 >> --- a/src/box/box.cc >> +++ b/src/box/box.cc >> @@ -1556,7 +1556,19 @@ box_clear_synchro_queue(bool try_wait) >> "new synchronous transactions appeared"); >> rc = -1; >> } else { >> - txn_limbo_force_empty(&txn_limbo, wait_lsn); >> + /* >> + * Term parameter is unused now, We'll pass >> + * box_raft()->term there later. >> + */ >> + txn_limbo_write_promote(&txn_limbo, wait_lsn, 0); >> + struct synchro_request req = { >> + .type = 0, /* unused */ >> + .replica_id = 0, /* unused */ >> + .origin_id = instance_id, >> + .lsn = wait_lsn, >> + .term = 0, /* unused */ > 1. Aren't the unused fields nullified anyway according to > the standard? We had this conversation with Cyrill recently. I don't have a good explanation for this anyway, but here's the one I have: >> Is there some particular meaning of zeroifying designated assignments? >> I mean why not simply >> >> struct synchro_request req = { >> .origin_id = instance_id, >> .lsn = wait_lsn, >> }; >> >> or you wanted to pay attention that the left of the fields are >> unused? Just curious, I'm fine with current code. > I went for your option at first, and it's the one I'd prefer. > But with it I got failed builds in some CI jobs. > > It said something like "sorry, not yet implemented: struct partial > initialization" > > >> + }; >> + txn_limbo_read_promote(&txn_limbo, &req); >> assert(txn_limbo_is_empty(&txn_limbo)); >> } >> } >> diff --git a/src/box/txn_limbo.c b/src/box/txn_limbo.c >> index d29722ef7..bfe0ad302 100644 >> --- a/src/box/txn_limbo.c >> +++ b/src/box/txn_limbo.c >> @@ -464,6 +470,32 @@ txn_limbo_read_rollback(struct txn_limbo *limbo, int64_t lsn) >> box_update_ro_summary(); >> } >> >> +void >> +txn_limbo_write_promote(struct txn_limbo *limbo, int64_t lsn, uint64_t term) >> +{ >> + limbo->confirmed_lsn = lsn; >> + /* >> + * We make sure that promote is only written once everything this >> + * instance has may be confirmed. >> + */ >> + struct txn_limbo_entry *e = txn_limbo_last_synchro_entry(limbo); >> + assert(e == NULL || e->lsn <= lsn); >> + (void) e; >> + txn_limbo_write_synchro(limbo, IPROTO_PROMOTE, lsn, term); >> + limbo->is_in_rollback = false; > 2. How is it possible that there was a rollback in progress at > the same time? Sorry, I was trying to replicate txn_limbo_write_confirm/rollback behaviour, but forgot to set limbo->is_in_rollback = true before the journal write: ======================================= diff --git a/src/box/txn_limbo.c b/src/box/txn_limbo.c index e6f644bc0..93c8994b7 100644 --- a/src/box/txn_limbo.c +++ b/src/box/txn_limbo.c @@ -474,6 +474,7 @@ void  txn_limbo_write_promote(struct txn_limbo *limbo, int64_t lsn, uint64_t term)  {         limbo->confirmed_lsn = lsn; +       limbo->is_in_rollback = true;         /*          * We make sure that promote is only written once everything this          * instance has may be confirmed. -- Serge Petrenko