From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id D05AB42EF5C for ; Tue, 23 Jun 2020 14:08:20 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id i27so22898028ljb.12 for ; Tue, 23 Jun 2020 04:08:20 -0700 (PDT) Date: Tue, 23 Jun 2020 14:08:18 +0300 From: Konstantin Osipov Message-ID: <20200623110818.GB6291@atlas> References: <50a25fbae907f1b0d5406fb2e78d40d3e42a8a8d.1591029888.git.korablev@tarantool.org> <4a83c68d-2dfd-23a8-97cd-5a429639dc3c@tarantool.org> <20200619122412.GA19725@tarantool.org> <20200619124229.GB61079@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Aleksandr Lyapunov Cc: v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org * Aleksandr Lyapunov [20/06/23 08:16]: > > > > > 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. Makes sense. Make sense now, when we yield only to read from disk. In future we may consider yielding for other reasons, but this looks like something rather distant.. > 2. a dozen of lines of code is removed - the cost of support is lowered a > bit. -- Konstantin Osipov, Moscow, Russia