Skip site navigation (1) Skip section navigation (2)

Re: bug of recovery?

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug of recovery?
Date: 2011-09-27 05:54:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 26.09.2011 21:06, Simon Riggs wrote:
> On Mon, Sep 26, 2011 at 10:50 AM, Fujii Masao<masao(dot)fujii(at)gmail(dot)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

In response to


pgsql-hackers by date

Next:From: Brar PieningDate: 2011-09-27 05:58:16
Subject: Re: Support UTF-8 files with BOM in COPY FROM
Previous:From: Fujii MasaoDate: 2011-09-27 05:51:38
Subject: Re: Online base backup from the hot-standby

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group