Re: corruption of WAL page header is never reported
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: masao.fujii@oss.nttdata.com
Cc: nagata@sraoss.co.jp, ranier.vf@gmail.com, pgsql-hackers@postgresql.org
Date: 2021-09-02T04:31:31Z
Lists: pgsql-hackers
Sorry, please let me add something. At Thu, 02 Sep 2021 13:17:16 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > At Thu, 2 Sep 2021 12:19:25 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in > > Also I'm tempted to move ereport() and reset of errmsg_buf to > > under next_record_is_invalid as follows. That is, in standby mode > > whenever we find an invalid record and retry reading WAL page > > in XLogPageRead(), we report the error message and reset it. > > For now in XLogPageRead(), only XLogReaderValidatePageHeader() > > sets errmsg_buf, but in the future other code or function doing that > > may be added. For that case, the following change seems more elegant. > > Thought? > > I don't think it is good choice to conflate read-failure and header > validation failure from the view of modularity. In other words, XLogReaderValidatePageHeader is foreign for XLogPageRead and the function indeuces the need of extra care for errormsg_buf that is not relevant to the elog-capable module. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Make recovery report error message when invalid page header is found.
- 7b03d3a3ba45 12.17 landed
- 5dc093eacef1 13.13 landed
- 2f13e8d9ec28 14.10 landed
- 68601985e699 15.0 landed
-
Fix scenario where streaming standby gets stuck at a continuation record.
- 066871980183 11.0 cited