Re: Streaming replication and WAL archive interactions

> On 12 Feb 2026, at 09:56, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> Your “shared” archive mode addresses this: the standby keeps WAL until it’s archived. archive_mode=always plus an archive tool can work, but it’s expensive. In WAL-G, for example, the archive command does a GET on the standby’s WAL, then decrypts and compares. Switching to HEAD would reduce cost in some clouds but still adds cost.

Hi Andrey,

I think XLogArchiveCheckDone() needs adjustment for the shared archive mode.

Currently:
if (!XLogArchivingAlways() &&
GetRecoveryState() == RECOVERY_STATE_ARCHIVE)
return true;

On a standby being in RECOVERY_STATE_ARCHIVE and with archive_mode=shared WAL is considered deletable. My question is whether we expect this or not.

This means that XLogArchiveCheckDone() returns true before reaching the archival status checks from an active primary.

For archive_mode=on this early return is correct - nobody archives on the standby, so checking .done/.ready would block WAL cleanup forever? But shared mode relies on those files to defer recycling until the primary confirms archival.

Additionally, being in RECOVERY_STATE_ARCHIVE could falsify my reasoning. But I don't think that being in archive recovery means we don't need to persist WAL segment files because they are already in the archive. If the standby has not received a successful archival report from the primary, those WAL segments have not been archived yet - I am not sure if it's possible to have such a situation during RECOVERY_STATE_ARCHIVE where some WAL segments have not yet been archived by the primary.

I think shared mode needs to be excluded from this early return, but I am not sure about other details and my questions above:

if (!XLogArchivingAlways() &&
XLogArchiveMode != ARCHIVE_MODE_SHARED &&
GetRecoveryState() == RECOVERY_STATE_ARCHIVE)
return true;

Thoughts?

Best,
Jaroslav