Re: Re: Optimize crash recovery

On Sat, Mar 14, 2020 at 5:31 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> On 2020-Mar-14, Thunder wrote:
> > For example, if page lsn in storage is 0x90000 and start to replay from 0x10000.
> > If 0x10000 is full-page xlog record, then we can ignore to replay xlog between 0x10000~0x90000 for this page.
> >
> > Is there any correct issue if the page exists in the buffer pool and
> > ignore to replay for full-page or init page if page lsn is larger than
> > the lsn of xlog record?
>
> Oh! right. The assumption, before we had page-level checksums, was that
> the page at LSN 0x90000 could have been partially written, so the upper
> half of the contents would actually be older and thus restoring the FPI
> (and all subsequent WAL changes) was mandatory. But if the page
> checksum verifies, then there's no need to return the page back to an
> old state only to replay everything to bring it to the new state again.
>
> This seems a potentially worthwhile optimization ...

One problem is that you now have to read the block from disk, which
causes an I/O stall if the page is not already in the kernel page
cache. That could be worse than the cost of replaying all the WAL
records you get to skip with this trick. My WAL prefetching patch[1]
could mitigate that problem to some extent, depending on how much
prefetching your system can do. The current version of the patch has
a GUC wal_prefetch_fpw to control whether it bothers to prefetch pages
that we a FPI for, because normally there's no point, but with this
trick you'd want to turn that on.

[1] https://commitfest.postgresql.org/27/2410/