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 C20C76EC5D; Thu, 8 Apr 2021 13:19:20 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C20C76EC5D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1617877160; bh=3AhKW3YX8hAd9c7ZO3XMfHuTEYSnp/ivzcQX/Q24clM=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=ghCmbfPjwqVI2qBxZyv1V8u0thwh8pCDmd02Y16eR07gNJdttGw6btqgM+Y3oPMJf qmk7EDQGJpsghbx1izU6Q3Zb+FMhqmm82XQ2NZOYLuUBAusv7GaUglpS+JNd8iWUE8 NTDbEfCjKtpfwWGUpIKKQ1AkLYYWeKgK70jOuew0= Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C72346EC5D for ; Thu, 8 Apr 2021 13:19:18 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C72346EC5D Received: by mail-lf1-f47.google.com with SMTP id g8so3015216lfv.12 for ; Thu, 08 Apr 2021 03:19:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=D2BbwfAktRhZ6TY6FZhRJTG1obC3CXwmmfYxD1lYons=; b=eL2NzqTYIzBPQDXOVfbNDkWzXP26Jn5YHJOsiWpWnfM/x3j1uGGC/o8tU9u9C49fPO 5T+Z/o54k0RmJLGyKMA7H8ttstc/0bXS+YvkhVN/BYFeYdiQ9af9KjMs0TZJlQBeif8N 9/O16JCF1j0BFW9Pnl5AzqG8n9IF+DALAO1x/ihiaEtzGaoS3j1iwKGkMHGh5qWVfiOW tQNRcKI7F7cLp4TweCunAKwVWbjib0EjWUD3QjP77ImhAWAfVxnZD/X0Uiw2BIXFg4Bu nMEE51bwAKcaPUHhJ23kQ60uv5ya421gBbYOYmwDhMJOHFWMAsXDaZNY007zMu0qVD9v hhSA== X-Gm-Message-State: AOAM530CxUIHsPqMstpiuC98xsPYFyqlY3/EgjpRqCd3b20Rjhgj3fHQ lbchkfyPnQ2w2dH++8n9ei1Up4I4BTA= X-Google-Smtp-Source: ABdhPJzZUeiYrdJwRW08VHST4TWsK4VIpNUhw/iXslaPheDwcNIR1dyxvgnZzVBbHAwVDTdD/TJYgA== X-Received: by 2002:ac2:5f56:: with SMTP id 22mr5506929lfz.35.1617877157772; Thu, 08 Apr 2021 03:19:17 -0700 (PDT) Received: from grain.localdomain ([5.18.199.94]) by smtp.gmail.com with ESMTPSA id f27sm2797984lfk.44.2021.04.08.03.19.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 03:19:16 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id A013E56015C; Thu, 8 Apr 2021 13:19:15 +0300 (MSK) Date: Thu, 8 Apr 2021 13:19:15 +0300 To: Serge Petrenko Cc: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org Message-ID: References: <00c39bc5e3090383a5f0e732b5a1f32130191cf1.1617835503.git.v.shpilevoy@tarantool.org> <71ee3907-a8fd-d916-fc6a-3205e66f2d29@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71ee3907-a8fd-d916-fc6a-3205e66f2d29@tarantool.org> User-Agent: Mutt/2.0.5 (2021-01-21) 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: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 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? > 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.