Re: Switching XLog source from archive to streaming when primary available

Hi,

On Mon, Aug 24, 2026 at 4:05 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
> Reviving this thread - the discussion so far has mostly centered on
> whether streaming or archive recovery is faster, and understandably
>
> In short: the disk-exhaustion risk on the primary, and the
> logical-replication stall under slot sync, both stem from the standby
> staying in archive mode longer than necessary regardless of whether
> streaming would technically be faster in a given environment. I would
> suggest we evaluate this patch primarily against that concern, and
> treat the performance angle as a secondary benefit rather than the
> main justification.
>
> I will rebase the patch (last posted as v24) and follow up with an
> updated version if there's interest in continuing this.

Thanks, Ashutosh, for picking this up.

Having the replay source order (pg_wal, archive, streaming) as a GUC
with the default being the current order or none (behaves the same as
today, move to streaming once all WAL files from archive and pg_wal
are emptied) makes sense.

Although fetching from archive could be much faster (with parallel
restoring of a batch of WAL files without going through the
replication protocol), as rightly mentioned upthread, a transiently
failed archive network or storage could lead to the primary's disk
filling up or blocking logical replication, and perhaps vacuum too.

Can we start by having some tests where the archive is in S3 or a
similar remote store and measure the latencies for fetching say 1000
or more WAL files from the archive vs the primary via streaming with a
simple restore command, and also the impact on the primary while the
standby stays in archive mode? This helps set some context for the use
case.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com