Re: Possible missing segments in archiving on standby

At Fri, 3 Sep 2021 02:06:45 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>
>
> On 2021/09/02 10:16, Kyotaro Horiguchi wrote:
> > Ok, I agree that the reader-side needs an amendment.
>
> Thanks for the review! Attached is the updated version of the patch.
> Based on my latest patch, I changed the startup process so that
> it creates an archive notification file of the streamed WAL segment
> including XLOG_SWITCH record if the notification file has not been
> created yet.

+ if (readSource == XLOG_FROM_STREAM &&
+ record->xl_rmid == RM_XLOG_ID &&
+ (record->xl_info & ~XLR_INFO_MASK) == XLOG_SWITCH)

readSource is the source at the time startup reads it and it could be
different from the source at the time the record was written. We
cannot know where the record came from there, so does the readSource
condition work as expected? If we had some trouble streaming just
before, readSource at the time is likely to be XLOG_FROM_PG_WAL.

+ if (XLogArchivingAlways())
+ XLogArchiveNotify(xlogfilename, true);
+ else
+ XLogArchiveForceDone(xlogfilename);

The path is used both for crash and archive recovery. If we pass there
while crash recovery on a primary with archive_mode=on, the file could
be marked .done before actually archived. On the other hand when
archive_mode=always, the file could be re-marked .ready even after it
has been already archived. Why isn't it XLogArchiveCheckDone?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center