On 26.09.2011 21:06, Simon Riggs wrote:
On Mon, Sep 26, 2011 at 10:50 AM, Fujii Masao<masao.fu...@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.
I think you're mixing this up with the multi-page page split operations
in b-tree. This is different from that. What the "invalid_page_tab" is
for is the situation where you for example, insert to a page on table X,
and later table X is dropped, and then you crash. On WAL replay, you
will see the insert record, but the file for the table doesn't exist,
because the table was dropped. In that case we skip the insert, note
what happened in invalid_page_tab, and move on with recovery. When we
see the later record to drop the table, we know it was OK that the file
was missing earlier. But if we don't see it before end of recovery, we
PANIC, because then the file should've been there.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
