Re: [HACKERS] BLK_DONE state in XLogReadBufferForRedoExtended

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] BLK_DONE state in XLogReadBufferForRedoExtended
Дата
Msg-id CAB7nPqQyQv5jJwroVdnKdK_2iFY3U4KqAgqaom5Uu74w1_EGuQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] BLK_DONE state in XLogReadBufferForRedoExtended  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] BLK_DONE state in XLogReadBufferForRedoExtended  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Oct 12, 2017 at 10:47 PM, Amit Kapila <amit.kapila16@gmail.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Log LDAP "diagnostic messages"?
Следующее
От: Noah Misch
Дата:
Сообщение: Re: [HACKERS] Still another race condition in recovery TAP tests