From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (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 2088D469710 for ; Sat, 30 May 2020 02:04:46 +0300 (MSK) Received: by mail-lj1-f181.google.com with SMTP id m18so1236264ljo.5 for ; Fri, 29 May 2020 16:04:46 -0700 (PDT) Date: Sat, 30 May 2020 02:04:43 +0300 From: Konstantin Osipov Message-ID: <20200529230443.GA209500@atlas> References: <776e8b91b93c79dabd2932b5d665236c5da313c8.1590546551.git.korablev@tarantool.org> <7445b38c-f664-ca79-bb05-73a73ddc4d6d@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7445b38c-f664-ca79-bb05-73a73ddc4d6d@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] vinyl: add NULL check of xrow_upsert_execute() retval List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [20/05/30 00:29]: > I don't know how to fix it in a simple way. The only thing I could > come up with is probably don't squash such fat upserts. Just keep > them all on the disk, until they eventually meet bottom of their key, > or a terminal statement like REPLACE/INSERT/DELETE. I wrote earlier about this problem in @tarantoolru. We need to balance the op limit and the squash threshold (how many upserts we keep before forcing a squash) so that accumulation before squash can never lead to going out of the op limit. Basically, we should force squash before we have a chance of creating an invalid upsert. We could even have a separate constant - number of ops in *user* upsert, which == max_number_of_ops/max_upserts_before_forced_squash. -- Konstantin Osipov, Moscow, Russia