Re: corruption of WAL page header is never reported - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: corruption of WAL page header is never reported
Date
Msg-id 8370e15f-92a3-1065-77f3-9ab2aee3f9a3@oss.nttdata.com
Whole thread Raw
In response to Re: corruption of WAL page header is never reported  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: corruption of WAL page header is never reported
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Separate out FileSet from SharedFileSet (was Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o)
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: pg_receivewal starting position