Hi, On Mon, Aug 24, 2026 at 4:05 AM Ashutosh Sharma <[email protected]> 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
