Re: 回复： Why is XLOG_FPI_FOR_HINT always need backups?

On 2021/07/07 16:11, Kyotaro Horiguchi wrote:
> Hello.
>
> At Tue, 6 Jul 2021 20:42:23 +0800, "zwj" <757634191(at)qq(dot)com> wrote in
>> But I wonder whether it is necessary or not while my file system can protect the blocks of database to be torn. And I read a comment in function&nbsp;MarkBufferDirtyHint:
>>
>> /*
>> * If we need to protect hint bit updates from torn writes, WAL-log a
>> * full page image of the page. This full page image is only necessary
>> * if the hint bit update is the first change to the page since the
>> * last checkpoint.
>> *
>> * We don't check full_page_writes here because that logic is included
>> * when we call XLogInsert() since the value changes dynamically.
>> */
>>
>> However, the code tell me it has nothing to do with full_page_writes. I can't figure it out.
>
> The doc of wal_log_hints says that "*even* for non-critical
> modifications of so-called hint bits", which seems to me implies it is
> following full_page_writes (and I think it is nonsense otherwise, as
> you suspect).
>
> XLogSaveBufferForHint sets REGBUF_FORCE_IMAGE since 2c03216d83116 when
> the symbol was introduced. As my understanding XLogInsert did not have
> an ability to enforce FPIs before the commit. The code comment above
> is older than that commit. So it seems to me a thinko that
> XLogSaveBufferForHint sets REGBUF_FORCE_IMAGE.
>
> I think the attached fixes that thinko.

With the patch, I got the following error during crash recovery.
I guess this happened because XLOG_FPI_FOR_HINT record had
no backup blocks even though the replay logic for XLOG_FPI_FOR_HINT
assumes it contains backup blocks.

FATAL: unexpected XLogReadBufferForRedo result when restoring backup block
CONTEXT: WAL redo at 0/169C600 for XLOG/FPI_FOR_HINT: ; blkref #0: rel 1663/13236/16385, blk 0

Regards,

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