Re: corruption of WAL page header is never reported
От | Fujii Masao |
---|---|
Тема | Re: corruption of WAL page header is never reported |
Дата | |
Msg-id | 8370e15f-92a3-1065-77f3-9ab2aee3f9a3@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: corruption of WAL page header is never reported (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: corruption of WAL page header is never reported
|
Список | pgsql-hackers |
On 2021/09/02 13:17, Kyotaro Horiguchi wrote: > Did you read the comment just above? Yes! > > xlog.c:12523 >> * Check the page header immediately, so that we can retry immediately if >> * it's not valid. This may seem unnecessary, because XLogReadRecord() >> * validates the page header anyway, and would propagate the failure up to >> * ReadRecord(), which would retry. However, there's a corner case with >> * continuation records, if a record is split across two pages such that > > So when not in standby mode, the same check is performed by xlogreader > which has the responsibility to validate the binary data read by > XLogPageRead. The page-header validation is a compromise to save a > specific case. Yes, so XLogPageRead() can skip the validation check of page head if not in standby mode. On the other hand, there is no problem if it still performs the validation check as it does for now. No? > I don't think it is good choice to conflate read-failure and header > validation failure from the view of modularity. I don't think that the proposed change does that. But maybe I failed to get your point yet... Anyway the proposed change just tries to reset errormsg_buf whenever XLogPageRead() retries, whatever error happened before. Also if errormsg_buf is set at that moment, it's reported. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: