Re: corruption of WAL page header is never reported

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: alvherre(at)alvh(dot)no-ip(dot)org, nagata(at)sraoss(dot)co(dot)jp, ranier(dot)vf(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: corruption of WAL page header is never reported
Date: 2021-10-04 15:59:46
Message-ID: 1c66a402-0341-c733-e0fd-9016e2028149@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/09/13 17:21, Kyotaro Horiguchi wrote:
> I wrote "while not in standby mode, we don't need to avoid retry the
> entire record" but that doesn't mean the inversion "while in standby
> mode, we need to do avoid that". In the first place retry doesn't
> happen while not in standby mode. I don't come up with a nice
> phrasing but something like this works?
>
> Note that we don't do this while not in standby mode because this is
> required only to avoid retrying this entire record for an invalid page
> header while in standby mode. Instead, ReadPageInternal() is
> responsible for validating the page header in that case.

I think that it's better to comment why "retry" is not necessary
when not in standby mode.

-------------------
When not in standby mode, an invalid page header should cause recovery
to end, not retry reading the page, so we don't need to validate the page
header here for the retry. Instead, ReadPageInternal() is responsible for
the validation.

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2021-10-04 16:14:37 Re: Support for NSS as a libpq TLS backend
Previous Message Mark Dilger 2021-10-04 15:10:28 Re: BUG #17212: pg_amcheck fails on checking temporary relations