On Fri, Oct 24, 2025 at 1:25 AM Andrey Borodin <[email protected]> wrote: > > Hi hackers, > > I'd like to propose a new archive_mode setting to address a gap in WAL > archiving for high availability streaming replication configurations. > > ## Problem > > In HA setups using streaming replication, standbys can be > promoted when primary has failed. Some WAL segments might be not yet > archived. This creates gaps in the WAL archive, breaking point-in-time > recovery: > > 1. Primary generates WAL, streams to standby > 2. Standby receives WAL, marks segments as .done immediately > 3. Standby deletes WAL during checkpoints > 4. Primary hasn't archived yet (archiver lag, network issues, etc.) > 5. Primary vanishes > 6. Standby gets promoted > 7. WAL history lost from archive > > This is particularly problematic in synchronous replication where > promotion might happen while the primary is still catching up on archival. > > Promoted standby might have some WALs from walreceiver, some from archive. In > this case we need to archive only those WALs which were received, but not > confirmed to be archived by primary. > > ## Proposed Solution > > Add archive_mode=follow_primary, where standbys defer WAL deletion until > the primary confirms archival:
Can't we achieve nearly the same behavior by setting archive_mode to always and configuring archive_command on the standby to check whether the WAL file already exists in the shared archive area (e.g., test -f <archive directory>/%f (probably also the WAL file size should be checked))? In this setup, archive_command would fail until the WAL file appears in the archive, preventing the standby from removing it while the command is failing. Regards, -- Fujii Masao
