Re: Possible missing segments in archiving on standby
От | Fujii Masao |
---|---|
Тема | Re: Possible missing segments in archiving on standby |
Дата | |
Msg-id | 19d4a303-6ee3-444f-7c99-e78dde1c5a94@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Possible missing segments in archiving on standby (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Possible missing segments in archiving on standby
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: