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 |
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 |