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? 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. 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?
In the first place A and B happens only at termination or crash of walsender so there's no fragility in checking only the previous segment at start of walsender. After a bit thought I noticed that we don't need to do that in the wal-writing loop. And I noticed that we need to consider timeline transitions while calculating the previous segment. Even though missing-notification at a timeline-switch doesn't happen unless walsender is killed hard for example by a sigkill or a power cut, though.
What happens if the server is promoted before that walreceiver is invoked? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
