Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWmB4-0006gE-Fc for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2022 22:08:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oWmB3-0007XO-78 for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2022 22:08:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWm7w-0001aH-CY for pgsql-hackers@lists.postgresql.org; Fri, 09 Sep 2022 22:05:32 +0000 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oWm7r-0004VJ-TK for pgsql-hackers@lists.postgresql.org; Fri, 09 Sep 2022 22:05:32 +0000 Received: by mail-pj1-x102a.google.com with SMTP id pj10so2702024pjb.2 for ; Fri, 09 Sep 2022 15:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=XHaImkvLbuMPplANMVt0k3epJtDzf4oXsWTOnIBgDUc=; b=IarCf8Fn7BjTOWFWyyHFx2kQiMcwd/fZhVHv0WL48WTganGnOIvqrZSmqi8Z0+B9m3 G1Du744fl5BVbprb1DoL1cn0gkhNTCSMHnKRIiUzDG6ilkl7HuQ8w4u0j4RZJZFwqcPm LnL7AFU7CyTf9MoBxSIrHaEvNl+9tOdDk2qOvqJQT6xAD/pGnznX12iUshtRNe+V6hkE f0KYWnOPq/019X+vwpa5C7hGc5IxVDM6UhklbyGMbZypcTCIKXvk0msLQo5ZSasnGM8a UwZmGDo1UfmtVq9fQ32QC9Ir0ZfzmIxwwvTjiVZvj+beln2h18D3Rv6WBZY946YvT34m WfOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=XHaImkvLbuMPplANMVt0k3epJtDzf4oXsWTOnIBgDUc=; b=WPmzaS9eX3SoCbwFPhrQeKVZQN685Ra/ke2BICE9ngOvz5ImFHnrufeXvOFYqLZSEg /XAomIm4Cgm0+t2odrcAsowHcg1dMw7MT94IKsJw8XUlw4UdRC9IOa7MOJorqMoPjPRO HMOBjCtdBQgYG0dxy/zWJzM2Qts1O7OdL3+OaMot06AJHeXBdyTmXqvCGbLvXRs3eyXF LYuNgcZwUdPPRYErcDwyfUMfW/xhc9dvBugAs5I8yOV80nbS0+5citfHkqGctdyPF8BH O+nS+u1bKFCGW8yDnyKn88ot13BH6/xhqFcoobfzbyipgHeMrPubnpRcvo/8aszwn6cw lrng== X-Gm-Message-State: ACgBeo3wNOtO2l27tU5zyl4AU6rV/baGmRYWyZGyEUat0OvOiB4Lis/P A1TvWw/+Js7Ij94KQYBoW6k= X-Google-Smtp-Source: AA6agR42/bJdjqwXkdWUHfSSOffNa2Pqq/MNoEWbbTSh+in/Zhv9DclPJf1heU6+Nkls72Uvp0M39g== X-Received: by 2002:a17:902:f78f:b0:174:d33d:1723 with SMTP id q15-20020a170902f78f00b00174d33d1723mr15621637pln.48.1662761125831; Fri, 09 Sep 2022 15:05:25 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id g12-20020aa79f0c000000b005380c555ba1sm248270pfr.13.2022.09.09.15.05.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Sep 2022 15:05:25 -0700 (PDT) Date: Fri, 9 Sep 2022 15:05:23 -0700 From: Nathan Bossart To: Bharath Rupireddy Cc: Kyotaro Horiguchi , cary.huang@highgo.ca, pgsql-hackers@lists.postgresql.org, satyanarlapuram@gmail.com Subject: Re: Switching XLog source from archive to streaming when primary available Message-ID: <20220909220523.GA2258997@nathanxps13> References: <20220906215704.GA2084086@nathanxps13> <20220908175356.GA2225645@nathanxps13> <20220909.142657.1730100023574894984.horikyota.ntt@gmail.com> <20220909165950.GB2254174@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Sep 09, 2022 at 11:07:00PM +0530, Bharath Rupireddy wrote: > On Fri, Sep 9, 2022 at 10:29 PM Nathan Bossart wrote: >> IMO the timeout approach would be more intuitive for users. When it comes >> to archive recovery, "WAL segment" isn't a standard unit of measure. WAL >> segment size can differ between clusters, and WAL files can have different >> amounts of data or take different amounts of time to replay. > > How about the amount of WAL bytes fetched from the archive after which > a standby attempts to connect to primary or enter streaming mode? Of > late, we've changed some GUCs to represent bytes instead of WAL > files/segments, see [1]. Well, for wal_keep_size, using bytes makes sense. Given you know how much disk space you have, you can set this parameter accordingly to avoid retaining too much of it for standby servers. For your proposed parameter, it's not so simple. The same setting could have wildly different timing behavior depending on the server. I still think that a timeout is the most intuitive. >> So I think it >> would be difficult for the end user to decide on a value. However, even >> the timeout approach has this sort of problem. If your parameter is set to >> 1 minute, but the current archive takes 5 minutes to recover, you won't >> really be testing streaming replication once a minute. That would likely >> need to be documented. > > If we have configurable WAL bytes instead of timeout for standby WAL > source switch from archive to primary, we don't have the above problem > right? If you are going to stop replaying in the middle of a WAL archive, then maybe. But I don't think I'd recommend that. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com