At Wed, 1 Sep 2021 14:37:43 +0900, Fujii Masao <masao.fu...@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