Re-archive the WAL on standby with archive_mode=always？

On Mon, Jul 21, 2025 at 2:38 PM Japin Li <japinli@hotmail.com> wrote:

Hi, hackers,

I was recently reviewing the KeepFileRestoredFromArchive() function and came
across a section that raised a question for me:

/*
* Create .done file forcibly to prevent the restored segment from being
* archived again later.
*/
if (XLogArchiveMode != ARCHIVE_MODE_ALWAYS)
XLogArchiveForceDone(xlogfname);
else
XLogArchiveNotify(xlogfname);

My understanding is that the WAL segment in this context has just been
restored from the archive.

However, for archive_mode=always, the code calls XLogArchiveNotify(xlogfname),
which, if I understand correctly, signals the archiver to re-archive this
already-archived WAL segment.

Is there a specific scenario or benefit I'm overlooking?

One possible scenario is when the archive directory used by restore_command
is different from the one used by archive_command. For example, the primary
and standby servers might each have their own separate archive directories,
with archive_command configured to archive WAL files to their
respective directories.
Meanwhile, the standby’s restore_command might be set up to fetch WAL files
from the primary’s archive directory. This kind of setup can be used
when there’s
no shared archive directory between the primary and standby. In such cases,
even WAL files restored on the standby might need to be archived again.

Regards,

--
Fujii Masao

On Wed, 23 Jul 2025 at 09:24, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Jul 21, 2025 at 2:38 PM Japin Li <japinli@hotmail.com> wrote:

Hi, hackers,

I was recently reviewing the KeepFileRestoredFromArchive() function and came
across a section that raised a question for me:

/*
* Create .done file forcibly to prevent the restored segment from being
* archived again later.
*/
if (XLogArchiveMode != ARCHIVE_MODE_ALWAYS)
XLogArchiveForceDone(xlogfname);
else
XLogArchiveNotify(xlogfname);

My understanding is that the WAL segment in this context has just been
restored from the archive.

However, for archive_mode=always, the code calls XLogArchiveNotify(xlogfname),
which, if I understand correctly, signals the archiver to re-archive this
already-archived WAL segment.

Is there a specific scenario or benefit I'm overlooking?

One possible scenario is when the archive directory used by restore_command
is different from the one used by archive_command. For example, the primary
and standby servers might each have their own separate archive directories,
with archive_command configured to archive WAL files to their
respective directories.
Meanwhile, the standby’s restore_command might be set up to fetch WAL files
from the primary’s archive directory. This kind of setup can be used
when there’s
no shared archive directory between the primary and standby. In such cases,
even WAL files restored on the standby might need to be archived again.

Thanks for your explanation.

Yes, I've encountered this exact scenario: when promoting a standby and then
re-joining the old primary, they maintain separate WAL archive directories.
I've attached a script to reproduce this.

I've observed that WalReceiverMain() archives WALs upon receipt, and
StartupXLOG() subsequently restores them from the archive directory, and then
re-archives them via KeepFileRestoredFromArchive().

--
Regards,
Japin Li