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 по дате отправления:

Предыдущее
От: Brar Piening
Дата:
Сообщение: Re: Support UTF-8 files with BOM in COPY FROM
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] Fix Leaky View Problem