From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BLK_DONE state in XLogReadBufferForRedoExtended |
Date: | 2017-10-13 05:02:29 |
Message-ID: | CAB7nPqQyQv5jJwroVdnKdK_2iFY3U4KqAgqaom5Uu74w1_EGuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 12, 2017 at 10:47 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Today, I was trying to think about cases when we can return BLK_DONE
> in XLogReadBufferForRedoExtended. One thing that occurred to me is
> that it can happen during the replay of WAL if the full_page_writes is
> off. Basically, when the full_page_writes is on, then during crash
> recovery, it will always first restore the full page image of page and
> then apply the WAL corresponding to that page, so we will never hit
> the case where the lsn of the page is greater than lsn of WAL record.
>
> Are there other cases for which we can get BLK_DONE state? Is it
> mentioned somewhere in code/comments which I am missing?
Remember the thread about meta page optimization... Some index AMs use
XLogInitBufferForRedo() to redo their meta pages and those don't have
a FPW so when doing crash recovery you may finish by not replaying a
meta page if its LSN on the page header is newer than what's being
replayed. That's another case where BLK_DONE can be reached, even if
full_page_writes is on.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2017-10-13 05:04:10 | Re: Still another race condition in recovery TAP tests |
Previous Message | Thomas Munro | 2017-10-13 04:37:30 | Re: Log LDAP "diagnostic messages"? |