> On 12 Feb 2026, at 09:56, Andrey Borodin <[email protected]> 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
