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 86C146FC8F; Tue, 23 Mar 2021 22:07:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 86C146FC8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616526478; bh=24jvOWQUDYeAmmIVHlhKEmOFEI2h8MDS3rPja4won78=; 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=XmbQF1djZUI1KPzftPZlAmdJYcRi8GBb/dAi8qamReqGX4DS4N5H4tjEEll6/qNtG eRhcHSX/ENKvRyvFPWCEtclp7yo62YmuAlNijkVtugwNvJYDWH7zzvpgJ4s6x4Yxua sLphUcwyXaz5bpvIhkzE8Ao9/DrlmHh2HwufFUDg= Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 E6F806FC8F for ; Tue, 23 Mar 2021 22:07:56 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E6F806FC8F Received: by mail-lj1-f179.google.com with SMTP id u4so27060652ljo.6 for ; Tue, 23 Mar 2021 12:07:56 -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=O66EHEsBeq9dUDHMEUG9VFJ13uycgF6DjIRnwu4iagw=; b=RviFIfHiBILElNbyjlwIZCNKRDDE/sTBjiFJxPNszPR79rqVR1SMBK45YAQXqNqe+A NlULgsE7sTsBzKFGLQxdf7p9xdR7uHG/eAekLnKftt2Rrf/cUk4VAH+yPvz4uqEFoM9e 4N59X2aUJyR6r1/UJ/pQT6VYLeHwNVnvnd5zIVZKORGS9+LGtsXy4e1L/HRgKSyoQgLC aH4IQucM+wriI5aXkDtRDwHVH3nFIMWt4oFR2Dc+yErs7+CsMvznom3pxrjXJt8kAVk5 g00rmJeigWK7MdOQs8sSn8TWAdDUyQ86QJ0iP5TMEty8rshA4LZ0K05pm9+pFqd0VrxP j9uw== X-Gm-Message-State: AOAM5332+m5Uj2tlSz9y5pB3pEYmduDGpT7NnlDpyKBypYaY6N55Y/8p IZhVyoQO8qL7j0eHCr+bqjxmQlL6TM8= X-Google-Smtp-Source: ABdhPJw77UZCglSIRThNIJ7tH92h9qRnxoouUexygUjTF6IDVZxHoWMLABAviTfGBqmE/OhmFjKlPA== X-Received: by 2002:a05:651c:39d:: with SMTP id e29mr4127837ljp.259.1616526475712; Tue, 23 Mar 2021 12:07:55 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id z7sm2360584ljo.64.2021.03.23.12.07.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 12:07:54 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id C0F3356017D; Tue, 23 Mar 2021 22:07:53 +0300 (MSK) Date: Tue, 23 Mar 2021 22:07:53 +0300 To: tml Message-ID: References: <20210323154710.1696442-1-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 v3 0/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: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Tue, Mar 23, 2021 at 09:33:45PM +0300, Cyrill Gorcunov wrote: > > > > issue https://github.com/tarantool/tarantool/issues/5806 > > branch gorcunov/gh-5806-xlog-gc-3 > > I just noticed that with this change the test replication/replica_rejoin.test.lua > started to fail. Investigating. I think it is due to default timeout. As far as I understand this is because our wal_cleanup_delay is not zero by default and doesn't allow to purge old xlog files until relays are connected back. In turn the test does exactly the reverse -- it expects main node to purge old xlogs. Actully I'm not sure what to do -- we can tune up the test case (ie explicitly set wal_cleanup_delay to 0) and it start passing but this looks like some backward compatiblity breakage: can't there be someone who relies to old behaviour? If so we should set wal_cleanup_delay to 0 by default, no? Cyrill