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
