From: Nathan Bossart <nathandbossart@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: cary.huang@highgo.ca
Cc: pgsql-hackers@lists.postgresql.org
Cc: satyanarlapuram@gmail.com
Subject: Re: Switching XLog source from archive to streaming when primary available
Date: Fri, 9 Sep 2022 15:05:23 -0700
Message-ID: <20220909220523.GA2258997@nathanxps13> (raw)
In-Reply-To: <CALj2ACW1qQ3-mTQXASc2UJHfS4iyqiidG=rG5U9042FcmuCtXg@mail.gmail.com>
References: <20220906215704.GA2084086@nathanxps13>
<CALj2ACVpCNuqtbj-2DmwvkZH588S7-h7Q4HvKBO-S-E0YhpPKQ@mail.gmail.com>
<20220908175356.GA2225645@nathanxps13>
<20220909.142657.1730100023574894984.horikyota.ntt@gmail.com>
<CALj2ACXOBXeGT--=unN1OYba0SXtxSQRNRHqrw8RHbEFKr6+5g@mail.gmail.com>
<20220909165950.GB2254174@nathanxps13>
<CALj2ACW1qQ3-mTQXASc2UJHfS4iyqiidG=rG5U9042FcmuCtXg@mail.gmail.com>
On Fri, Sep 09, 2022 at 11:07:00PM +0530, Bharath Rupireddy wrote:
> On Fri, Sep 9, 2022 at 10:29 PM Nathan Bossart <nathandbossart@gmail.com> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, bharath.rupireddyforpostgres@gmail.com, horikyota.ntt@gmail.com, cary.huang@highgo.ca, pgsql-hackers@lists.postgresql.org, satyanarlapuram@gmail.com
Subject: Re: Switching XLog source from archive to streaming when primary available
In-Reply-To: <20220909220523.GA2258997@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox