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 06AEF6EC5D; Thu, 8 Apr 2021 13:32:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 06AEF6EC5D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1617877928; bh=tKOjZxG/gz+q97QATkBIXNG9C06WKSuko8JQDtJ7gbw=; 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=KJ152/TiCVytxBXGg6bO/xns6sMEJRz/tveIAgFgqC/lCMRVW1wW/99/YsEdhgiCo qBDPpd8RgkAjlyaxScdLAQdkLoDeYu9kJGqQrswIEeLm1bjqvxqrJZS2i0IRQDA+XQ aDfwc2heqdOkXh7t5Qj8XXWsV0Q2AkiTCqSyubkc= Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (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 7F6F86EC5D for ; Thu, 8 Apr 2021 13:32:07 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 7F6F86EC5D Received: by smtp47.i.mail.ru with esmtpa (envelope-from ) id 1lURxG-0004t9-HE; Thu, 08 Apr 2021 13:32:07 +0300 To: Cyrill Gorcunov Cc: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org References: <00c39bc5e3090383a5f0e732b5a1f32130191cf1.1617835503.git.v.shpilevoy@tarantool.org> <71ee3907-a8fd-d916-fc6a-3205e66f2d29@tarantool.org> Message-ID: <72609da5-e79f-dd29-c69e-77090ea06df2@tarantool.org> Date: Thu, 8 Apr 2021 13:32:06 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 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: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD912A3E3D5D4B49FC1FB6C11AAC314D64EDF2811C24C4EA09700894C459B0CD1B95424B6240B9559AC0DA4491F2A73D3001E4707D8B8B41A8F377EF39409332766 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7C6068CE86C2B75F5EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637911538129B0A8D078638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B2ADB0D5DA93B89CF9A7E86BC4F2A0EA75EABCB1FA743BAAB4D2E47CDBA5A96583C09775C1D3CA48CFE478A468B35FE767117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE73AFA331E307B52169FA2833FD35BB23DF004C90652538430302FCEF25BFAB3454AD6D5ED66289B5278DA827A17800CE72E308E75DBE4A256D32BA5DBAC0009BE395957E7521B51C20BC6067A898B09E4090A508E0FED6299176DF2183F8FC7C00AC927CACCC12253CD04E86FAF290E2D7E9C4E3C761E06A71DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6D635BA3ABDB36C18089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5BADB4D527939D6DAC636C610B5DF769666DFAB9C9D94A602D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D346F8291983715AC665CCBA3230D50B297768B6C1EA6CCCBA87CCF0708E4B788B73C21C4C3204703EA1D7E09C32AA3244C3898176E8396BFDAF3582559E38EE74AF522A1CF68F4BE05FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioju+jaMfvANXorbr6Ud+qZrA== X-Mailru-Sender: 11C2EC085EDE56FAC07928AF2646A769BC14ECBFEFBB8376F289826C7AE2987E52685D71546B8E9E32C2A64043BFB05F66FEC6BF5C9C28D9D2F9AC31ED4B18F0B80F102789B70DF27402F9BA4338D657ED14614B50AE0675 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH 1/1] applier: process synchro rows after WAL write 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" 08.04.2021 13:19, Cyrill Gorcunov пишет: > On Thu, Apr 08, 2021 at 11:39:03AM +0300, Serge Petrenko wrote: >> Thanks for the patch! >> >> I'm a bit worried about two different synchro rows coming from two >> appliers. Is everything ok in this case? > Serge, you mean the scenario when some instances in replicaset > have the patch applied and some are not? No. Let's suppose everyone has this patch applied. Now look at one particular instance. It may happen that while one of its appliers is writing this synchro row (either CONFIRM or ROLLBACK, doesn't matter), some other applier may still apply requests coming from other replicaset members. I was wondering what would happen if someone else sent this instance another synchro row. Looks like nothing bad but I just wanted to double-check. And looks like there's a bug, which I'm speaking of below. It's about someone sending us normal rows (either synchronous transactions or asynchronous, but not CONFIRM/ROLLBACK entries) while we're waiting for syncro row's write to end. Say, limbo was owned by instance 1, and instance 2 has written CONFIRM for everything there was. While we wait for 2's CONFIRM to be written to WAL, we may receive some rows from instance 3, who has already applied 2's CONFIRM. Since we haven't written the CONFIRM yet, we haven't applied it, and the limbo on our instance still isn't empty. All the rows coming from 3 will get rejected and replication between 3 and us will be broken. > >> Or even normal rows coming from other appliers. Say some other replica >> has already applied this synchro row and even has written some rows on >> top of it. Its applier won't block on replica_id latch, and may fail to >> apply >> some txs following this synchro row, because it's not yet written to WAL >> and thus not applied (limbo is still not empty or belongs to other >> instance). >> >> Looks like this won't be a problem once synchro rows start pinning the >> limbo to some specific replica. Because in this case only the replica that >> has issued confirm will be able to generate new rows. And these rows will >> be ordered by replica_id latch. >> >> But still, maybe this is worth fixing? >> Am I missing something? >>> - struct journal_entry journal_entry; >>> + union { >>> + struct journal_entry base; >>> + char base_buf[sizeof(base) + sizeof(base.rows[0])]; >>> + }; >>> }; >> I don't understand this union stuff. >> The journal_entry is the last entry in synchro_entry anyway. >> Is this a hack for allowing to allocate synchro_entry on the stack? > Yeah, the journal_entry last member is zero size array so someone > has to preallocate memory for rows and using union allows to squash > everything statically on stack. Ok, I see now, thanks for the explanation! -- Serge Petrenko