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 EB5456B944; Tue, 13 Apr 2021 19:31:38 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EB5456B944 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618331499; bh=0sGvEB09WyfRDcTvRvAvDrwUHYHVGQvMfI41TdZo4kY=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=DX2EHYxdMvwVPttk/C3bd29G+3pV17QJPNGaPn6xu4WH9RZ98jpQUFr0U6xpAB80O pZNdYRjOvBRSsLg7trbnXqVRwALWzzmwOwjP3MRCQO+miqhsot+/8VciPXYM4C2ayL gIpArMDLtJsMimdt2HG35gK/K/vcwPqLNn9ThCuA= Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (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 EFE216BD2D for ; Tue, 13 Apr 2021 19:31:37 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EFE216BD2D Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1lWLwv-0005ut-5z; Tue, 13 Apr 2021 19:31:37 +0300 Date: Tue, 13 Apr 2021 19:31:35 +0300 To: Vladislav Shpilevoy Message-ID: <20210413163135.GA161184@tarantool.org> References: <91cec4dbcc1d931b70cdba3c70d77e7c58a00675.1617984948.git.imeevma@gmail.com> <0dc519d0-2c2c-4d88-0efa-f1dff782b9cc@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0dc519d0-2c2c-4d88-0efa-f1dff782b9cc@tarantool.org> X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E7480BE79914FF86F9151AC38CC435EA4A654182A05F538085040D1F3B4D877892C217A919C9D783043131C9B8AC9B9E5CE0A5293FC9A8AF64014 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE74FC7AD0AD96C1577EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006372E9841F416E2DCCD8638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B29CBBCE2FF410C5E26422F8399F9BBBC651ACFDFAE348AC99D2E47CDBA5A96583C09775C1D3CA48CFE478A468B35FE767117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE7850F8B975A76562C9FA2833FD35BB23DF004C906525384302BEBFE083D3B9BA73A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E7354E672349037D5FA5C4224003CC83647689D4C264860C145E X-C1DE0DAB: 0D63561A33F958A5BACA777E78291BDB1F249C4491B86349D202AAEB18CEDF2ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34060C3C6DE316ECE496C52A9EA4663352B3C016D61D321905AD4BE92760B38BA6ACDEB9196EF874C21D7E09C32AA3244C42F41276D97882BE7F36B182B992FA108580396430872480FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojnA7/qPBUIXEf9g3yA4wLYg== X-Mailru-Sender: 689FA8AB762F73936BC43F508A063822AA1BD540689F0B6C9C8D5EC94CCE1C4A83D72C36FC87018B9F80AB2734326CD2FB559BB5D741EB96352A0ABBE4FDA4210A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v5 14/52] sql: introduce mem_copy_as_ephemeral() 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: Mergen Imeev via Tarantool-patches Reply-To: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thank you for the review. My answer below. On Sun, Apr 11, 2021 at 08:10:19PM +0200, Vladislav Shpilevoy wrote: > Thanks for working on this! > > >>> @@ -593,9 +598,12 @@ sqlVdbeMemAboutToChange(Vdbe * pVdbe, Mem * pMem) > >>> int i; > >>> Mem *pX; > >>> for (i = 0, pX = pVdbe->aMem; i < pVdbe->nMem; i++, pX++) { > >>> - if (pX->pScopyFrom == pMem) { > >>> - pX->flags |= MEM_Undefined; > >>> - pX->pScopyFrom = 0; > >>> + if ((pX->flags & (MEM_Blob | MEM_Str)) != 0 && > >>> + (pX->flags & (MEM_Ephem | MEM_Static)) == 0) { > >>> + if (pX->pScopyFrom == pMem) { > >>> + pX->flags |= MEM_Undefined; > >>> + pX->pScopyFrom = 0; > >>> + } > >> > >> 2. Why did you change that? > >> > > This check is only useful for strings and binaries, since they may be lost due > > to change of another MEM. Also, due to this function it was possible that value > > of type other than MEM_Blob or MEM_Str will have MEM_Ephem set. This is wrong, I > > believe. > > Due to which function? sqlVdbeMemAboutToChange() does not set MEM_Ephem. I'm sorry, I was wrong. Actually it was sqlVdbeMemShallowCopy() fault that it was possible to MEM to have MEM_Ephem flag even though it was not a string or varbinary. But, since sqlVdbeMemMakeWriteable() was called in such cases after sqlVdbeMemShallowCopy(), this flag was removed, I think. About sqlVdbeMemAboutToChange() and MEM_undefined - I am not sure why I thought so. Most likely I come to this conclusion during investigation of why memIsValid() check fails when I removed sqlVdbeMemMakeWriteable() - this was so because MEM with MEM_Ephem was invalidated in sqlVdbeMemAboutToChange() even though the MEM wasn't string or varbinary.