At Wed, 1 Sep 2021 14:37:43 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>
>
> On 2021/09/01 12:12, Kyotaro Horiguchi wrote:
> > Putting aside the issue C, it would work as far as recovery is not
> > paused or delayed. Although simply doing that means we run additional
> > and a bit) wasteful XLogArchiveCheckDone() in most cases, It's hard to
> > imagine moving the responsibility to notify a finished segment from
> > walsender (writer side) to startup (reader side).
>
> You mean walreceiver, not walsender?
Sorry, it's walreceiver.
> I was thinking to apply my latest patch, to address the issue A and C.
> So walreceiver is still basically responsible to create .ready file.
Considering the following discussion, I don't object to the patch.
> Also regarding the issue B, I was thinking to make the startup process
> call XLogArchiveCheckDone() or something only when it finds
> XLOG_SWITCH record. Thought?
Sounds workable. I came to agree to the reader-side amendment as
below. But I might prefer to do that at every segment-switch in case
of a crash.
> What happens if the server is promoted before that walreceiver is
> invoked?
Hmmmmm. A partial segment is not created if a server promotes just at
a segment boundary, then the previous segment won't get archived until
the next checkpoint runs.
Ok, I agree that the reader-side needs an amendment.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center