From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (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 110624429E1 for ; Tue, 23 Jun 2020 08:15:54 +0300 (MSK) References: <50a25fbae907f1b0d5406fb2e78d40d3e42a8a8d.1591029888.git.korablev@tarantool.org> <4a83c68d-2dfd-23a8-97cd-5a429639dc3c@tarantool.org> <20200619122412.GA19725@tarantool.org> <20200619124229.GB61079@atlas> From: Aleksandr Lyapunov Message-ID: Date: Tue, 23 Jun 2020 08:15:53 +0300 MIME-Version: 1.0 In-Reply-To: <20200619124229.GB61079@atlas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [Tarantool-patches] [PATCH v2] vinyl: restart read iterator in case of rolled back WAL List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Nikita Pettik , tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org >>> The read iterator was rewritten several times and still have at least >>> several bugs. I think we should admit that we cannot support such a >>> complicated solution. How about some stupid solution: if ANY change >>> has been happened during yield - restart advancing? > Does this statement have technical merit? Is it supported by > tests? I'd gladly support the change if it was grounded in reason - > evaluation of the performance impact, for example, could serve as > a confirmation that a simple solution would be just fine. > > Without it, I'd it's a regress, a signature of helplessness, > lack of courage to make things right. Two reasons: 1. since we have to read from disk it's not a big deal to scan memory again. 2. a dozen of lines of code is removed - the cost of support is lowered a bit.