From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bug of recovery? |
Date: | 2011-09-26 17:15:18 |
Message-ID: | 8CFFA577-7145-473C-9E2B-8ACE08D5C16C@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sep26, 2011, at 11:50 , Fujii Masao 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?
Shouldn't references to invalid pages only occur before we reach a consistent
state? If so, the right fix would be to check whether all invalid page references
have been resolved after we've reached a consistent state, and to skip creating
restart points while there're unresolved page references.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-26 17:15:29 | Re: Support UTF-8 files with BOM in COPY FROM |
Previous Message | Tom Lane | 2011-09-26 17:10:27 | Re: random isolation test failures |