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 328606EC56; Fri, 19 Mar 2021 18:14:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 328606EC56 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616166890; bh=c3ACFoq/GGb9F0LKqt1tavu/kGHZZ/fgC3DFbiannTo=; 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=ly6c7S1umgqox0iRz8QRhocxQj0FVjU964HjOzFSxg0+pmRZtNBp2NjUDNiGZ2zzW ukcf4p1LfVyUANvq07iI/X6yVKZXiHlr0tsXf1iR/lFzu3WY/TrUKvS40thHgRMj8m iaTPDVrExuR+P1D1huPByJtNJ88EaCT4goOS6RqA= Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 399016EC56 for ; Fri, 19 Mar 2021 18:14:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 399016EC56 Received: by mail-lf1-f53.google.com with SMTP id q13so10534349lfu.8 for ; Fri, 19 Mar 2021 08:14:48 -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:content-transfer-encoding :in-reply-to:user-agent; bh=RjzgqjDszDWnXSm5PKjoDmWxi9H3VyKfOhmxvO5ncVo=; b=ewXNyrvTf4AMoXAhN3vg/FD2owKrIXKgto3LlRxSq32/X5JnuQhcaPLuL0A9Vd3pPU 5QWVfZpT3BNC3RGp10kOkmdIuO/pAP+lZd5LqtwSolYAOe1zIe/4TLsiwa1fai7UZUFA IjtkCnfLKe8G5l6KcuCUfmxaBsAJuLEwDXwY38kquXa5Ws7hqAOgRsvCsIPjj/MDfGbl KXmn2AcojASdOlu8pd6X41DBMWgT0opG/+BJVXwP7gGI730JxrW0mxljvdfLXs56LPhB hDH9i4PmmTTdmRqMJG6sQl75DrAuECFOXymN4IkkqUwohQRXXChGF6oRFXFIVo7+9rxp j0fQ== X-Gm-Message-State: AOAM5316867r/v6NZppCu7GGydytlIDDmiL3P2nQ7ZiNwjJCAn4cOtJO rglCpGndzvyPLPhgEN+H9hc= X-Google-Smtp-Source: ABdhPJyefd9sloTH6glAAc4CJZXMWpgl0wqj9Fs2rDjFpb4FhA3J3LsUVj7M1kSvQ/F0jfc1TnDu4A== X-Received: by 2002:a19:3850:: with SMTP id d16mr1131982lfj.473.1616166886312; Fri, 19 Mar 2021 08:14:46 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id m127sm653979lfa.181.2021.03.19.08.14.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Mar 2021 08:14:45 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 6F10F5601CD; Fri, 19 Mar 2021 18:14:44 +0300 (MSK) Date: Fri, 19 Mar 2021 18:14:44 +0300 To: Serge Petrenko Message-ID: References: <20210318184138.1077807-1-gorcunov@gmail.com> <20210318184138.1077807-2-gorcunov@gmail.com> <1482a9db-549e-e720-7a7c-6f052ebbcc73@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1482a9db-549e-e720-7a7c-6f052ebbcc73@tarantool.org> User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH 1/2] gc/xlog: delay xlog cleanup until relays are subscribed 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 Cc: Mons Anderson , tml , Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Fri, Mar 19, 2021 at 04:50:38PM +0300, Serge Petrenko wrote: > > +static void > > +box_check_wal_cleanup_delay(int tmo) > > +{ > > + if (tmo < 0 && tmo != -1) { > > + tnt_raise(ClientError, ER_CFG, "wal_cleanup_delay", > > + "the value must be either >= 0 or -1"); > > + } > > +} > > + > > > 1. AFAICS all other delay and timeout parameters are 'double'. >    Let's make this one also a double. Sure > > + /* > > + * Now we can resume wal/engine gc as relay > > + * is up and running. > > + */ > > + if (!relay->replica->anon) { > > + static const struct cmsg_hop gc_delay_route[] = { > > + {relay_gc_delay_unref, NULL} > > + }; > > + struct cmsg gc_delay_msg; > > + cmsg_init(&gc_delay_msg, gc_delay_route); > > + cpipe_push(&relay->tx_pipe, &gc_delay_msg); > > + } > > + > > 2. I agree with Vlad here. No need to call gc_delay_unref() from the relay > thread. >    We need to wait until a corresponding gc consumer is registered. This is > done >    in relay_subscribe(), which is in tx thread. > >    In fact, you may as well move the gc_delay_unref() call directly to > gc_consumer_register(). >    This would look even better, IMO. I don't mind to move it inside gc_consumer_register itself. Still this bothers me a bit, the gc_consumer_register might be used not only by relays since it is general api, would it be OK in a long term?