Re: corruption of WAL page header is never reported
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Yugo NAGATA <nagata@sraoss.co.jp>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2021-07-19T09:32:28Z
Lists: pgsql-hackers
Em seg., 19 de jul. de 2021 às 06:15, Yugo NAGATA <nagata@sraoss.co.jp> escreveu: > On Mon, 19 Jul 2021 17:47:07 +0900 (JST) > Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > > At Mon, 19 Jul 2021 16:00:39 +0900, Yugo NAGATA <nagata@sraoss.co.jp> > wrote in > > > Your patch doesn't fix the issue that the error message is never > reported in > > > standby mode. When a WAL page header is broken, the standby would > silently repeat > > > retrying forever. > > > > Ok, I see your point and agree to that. > > > > > I think we have to let users know the corruption of WAL page header > even in > > > standby mode, not? A corruption of WAL record header is always > reported, > > > by the way. (See that XLogReadRecord is calling ValidXLogRecordHeader.) > > > > Howeer, I'm still on the opinion that we don't need to check that > > while in standby mode. > > > > How about the attached? > > On Mon, 19 Jul 2021 17:50:16 +0900 (JST) > Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > > me> Howeer, I'm still on the opinion that we don't need to check that > > me> while in standby mode. > > > > Of course it's typo of "while not in standby mode". > > Thanks for updating the patch. I agree with you. > > I think it is nice to fix to perform the check only during standby mode > because it make a bit clearer why we check it immediately in XLogPageRead. > And as I had reviewed, your first patch was wrong and now with the Kyotaro version, to keep the same behavior, it is necessary to reset the error, correct? regards, Ranier Vilela
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