Re: bug of recovery?
| От | Simon Riggs |
|---|---|
| Тема | Re: bug of recovery? |
| Дата | |
| Msg-id | CA+U5nML8aK6iMpnaXf=vGYLCRkdqKUFJ6nTLTjEVpLj6oYYTRA@mail.gmail.com обсуждение исходный текст |
| Ответ на | bug of recovery? (Fujii Masao <masao.fujii@gmail.com>) |
| Ответы |
Re: bug of recovery?
Re: bug of recovery? |
| Список | pgsql-hackers |
On Mon, Sep 26, 2011 at 10:50 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > Currently, if a reference to an invalid page is found during recovery, > its information > is saved in hash table "invalid_page_tab". Then, if such a reference > is resolved, > its information is removed from the hash table. If there is unresolved > reference to > an invalid page in the hash table at the end of recovery, PANIC error occurs. > > What I'm worried about is that the hash table is volatile. If a user restarts > the server before reaching end of recovery, any information in the > hash table is lost, > and we wrongly miss the PANIC error case because we cannot find any unresolved > reference. That is, even if database is corrupted at the end of recovery, > a user might not be able to notice that. This looks like a serious problem. No? > > To prevent the above problem, we should write the contents of the hash table to > the disk for every restartpoints, I think. Then, when the server > starts recovery, > it should reload the hash table from the disk. Thought? Am I missing something? That doesn't happen because the when we stop the server it will restart from a valid restartpoint - one where there is no in-progress multi-phase operation. So when it replays it will always replay both parts of the operation. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: