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 a86d2f6f-0cca-57d8-a601-e44c5dd07edc@oss.nttdata.com
Whole thread Raw
In response to Re: corruption of WAL page header is never reported  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: corruption of WAL page header is never reported  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers

On 2021/09/07 2:02, Fujii Masao wrote:
> Even if we do this while NOT in standby mode, ISTM that this function doesn't
> return with a valid errmsg_buf because it's reset. So probably the comment
> should be updated as follows?
> 
> -------------------------
> We don't do this while not in standby mode because we don't need to retry
> immediately if the page header is not valid. Instead, XLogReadRecord() is
> responsible to check the page header.
> -------------------------

I updated the comment as above. Patch attached.

-     * it's not valid. This may seem unnecessary, because XLogReadRecord()
+     * it's not valid. This may seem unnecessary, because ReadPageInternal()
       * validates the page header anyway, and would propagate the failure up to

I also applied this change because ReadPageInternal() not XLogReadRecord()
calls XLogReaderValidatePageHeader().

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add jsonlog log_destination for JSON server logs
Next
From: Michael Paquier
Date:
Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats