> On 12 Feb 2026, at 09:56, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> Your “shared” archive mode addresses this: the standby keeps WAL until it’s archived. archive_mode=always plus an
archivetool can work, but it’s expensive. In WAL-G, for example, the archive command does a GET on the standby’s WAL,
thendecrypts 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
whetherwe 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
WALcleanup 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
recoverymeans we don't need to persist WAL segment files because they are already in the archive. If the standby has
notreceived a successful archival report from the primary, those WAL segments have not been archived yet - I am not
sureif it's possible to have such a situation during RECOVERY_STATE_ARCHIVE where some WAL segments have not yet been
archivedby 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
