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 9130F6FC8F; Tue, 23 Mar 2021 14:25:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9130F6FC8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616498731; bh=mHMMv3bbqNQ1R333ZunztnD4G5S2vfME2bWhskfxvdk=; 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=rI0qmTjiIkqLi5eCV0/tpELUypacvwdMbr10tX5hiIDrtdBfIBP7yN/nmJrpIPXRc V2xiDYqCDADFBahMpWdV3YazX4ZS03zMDqh1fgGfdPZ9LErK53FtiEW5betP97Eb+S +YdXGGAx3M8i86op7Z4+ou7OLolUVqenV/kTQw7Q= Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (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 BA79B6FC8F for ; Tue, 23 Mar 2021 14:25:30 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org BA79B6FC8F Received: by mail-lj1-f176.google.com with SMTP id a1so25137058ljp.2 for ; Tue, 23 Mar 2021 04:25:30 -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=RFFd6tzGiggzsp1rTDgrBoq22xm3AouHY/sqw9JGpuQ=; b=r85sk1VRKYF6DZ+ZZcmavrKWJwPhzV/S/3T1vSNi/aIw+lEf0RPJgdk/E7lbYnlBXB oaOcuEuJAB1n2Ibpv1PdPhbZrEzjo+BKubpGsTTUcRYY1qOuaOlhjP3Q7ETCCjQIennn ul/95V019l6QyM5XDcDoBNmhA99HE3LPHU8tSUV5DLs1hS20EaiuWTMuzyv38BqA32L5 PoOCL0jjK9FvBWtGq+Qjn01q6YzLS2JyKHORQBKhBSkYV0Vv0VkcO5/eIOg81/LVVhsi 9P8OErwUYUvmziCg3KsC4BCL0KAI2lxpw4DnX67WiaqD1cwHZ9ZjSl3lhoOz9rRn6c9i wF6w== X-Gm-Message-State: AOAM531/OG6S/b0fsMg+FyGMLH5kpBck5bYR7NJvT35gr9SQCTVYFPoV 0VxGheKb2i7ILQy/MFus0Qg= X-Google-Smtp-Source: ABdhPJwnb2K0PlK505/MquQ+LNvfa9dDmvDHz+hNR0pfhEZQI+MkGwDh8wdyFl27T1c2W9ukZKXWYw== X-Received: by 2002:a2e:94c8:: with SMTP id r8mr2825088ljh.332.1616498730176; Tue, 23 Mar 2021 04:25:30 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id b30sm1820557lfj.101.2021.03.23.04.25.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 04:25:28 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 0114556017D; Tue, 23 Mar 2021 14:25:26 +0300 (MSK) Date: Tue, 23 Mar 2021 14:25:26 +0300 To: Vladislav Shpilevoy Message-ID: References: <20210320131521.1249747-1-gorcunov@gmail.com> <20210320131521.1249747-2-gorcunov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH v2 1/3] 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 Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Tue, Mar 23, 2021 at 10:28:46AM +0300, Cyrill Gorcunov wrote: > > > > > Also you should use 'replication_anon' global variable instead > > of the config, which might be not installed at this moment yet. > > What would happen if one setup both 'wal_cleanup_delay' and > 'replication_anon' in config at once. Which C's replication_anon > value I will be reading? The C's replication_anon is set after > the cfg procedure complete, so since I operate on values obrained > from Lua level I need to use cfg_geti("replication_anon") because > at this moment only Lua level is consistent and replication_anon > may have a value from previous box.cfg call. Vlad, here are some moments I don't understand. 1) gc_init is called from box_cfg_xc, and here is a call chain box.cfg{} box.cfg = locked(load_cfg) pcall(private.cfg_check) -- goes into C layer -- lbox_cfg_check box_check_config ... box_check_replication if (box_check_wal_cleanup_delay() < 0) diag_raise(); here either all values are sane and passes the tests, or configuration stage aborts -- back to Lua level -- lbox_cfg_load -- jusmp to C again -- box_cfg box_cfg_xc ... gc_init(box_check_wal_cleanup_delay()); here the box_check_wal_cleanup_delay won't fail because it is already verified but we can't be sure that any dependent variable (as global replication_anon) been already set or not. And we should not bound to order of box_check_wal_cleanup_delay() invocation relatively to some other helpers. Thus I think we should use cfg_geti("replication_anon") inside box_check_wal_cleanup_delay code instead because only the level cfg_x() is consistent here. On reconfiguration stage the scheme is similar we must not access C's global replication_anon variable which is rather a cached value from cfg_geti("replication_anon"). Am I convinced you? I mean current code with access to cfg_geti("replication_anon") looks more preferred.