Re: Make mesage at end-of-recovery less scary.

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: ashu(dot)coek88(at)gmail(dot)com
Cc: pashkin(dot)elfe(at)gmail(dot)com, michael(at)paquier(dot)xyz, bossartn(at)amazon(dot)com, david(at)pgmasters(dot)net, peter(dot)eisentraut(at)2ndquadrant(dot)com, andres(at)anarazel(dot)de, pgsql-hackers(at)lists(dot)postgresql(dot)org, jtc331(at)gmail(dot)com, robertmhaas(at)gmail(dot)com
Subject: Re: Make mesage at end-of-recovery less scary.
Date: 2022-03-02 02:17:04
Message-ID: 20220302.111704.2121338146198619205.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Sat, 19 Feb 2022 09:31:33 +0530, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote in
> The changes looks good. thanks.!

Thanks!

Some recent core change changed WAL insertion speed during the TAP
test and revealed one forgotton case of EndOfWAL. When a record
header flows into the next page, XLogReadRecord does separate check
from ValidXLogRecordHeader by itself.

> * If the whole record header is on this page, validate it immediately.
> * Otherwise do just a basic sanity check on xl_tot_len, and validate the
> * rest of the header after reading it from the next page. The xl_tot_len
> * check is necessary here to ensure that we enter the "Need to reassemble
> * record" code path below; otherwise we might fail to apply
> * ValidXLogRecordHeader at all.
> */
> if (targetRecOff <= XLOG_BLCKSZ - SizeOfXLogRecord)
> {
...
> }
> else
> {
> /* XXX: more validation should be done here */
> if (total_len < SizeOfXLogRecord)
> {

I could simplly copy-in a part of ValidXLogRecordHeader there but that
results in rather large duplicate code. I could have
ValidXLogRecordHeader handle the partial header case but it seems to
me complex.

So in this version I split the xl_tot_len part of
ValidXLogRecordHeader into ValidXLogRecordLength.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v15-0001-Make-End-Of-Recovery-error-less-scary.patch text/x-patch 18.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2022-03-02 02:43:15 Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Previous Message Amit Kapila 2022-03-02 02:12:50 Re: pg_stat_get_replication_slot and pg_stat_get_subscription_worker incorrectly marked as proretset