Message-ID: <4E816532.4050904@enterprisedb.com>
Date: Tue, 27 Sep 2011 07:54:58 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13
MIME-Version: 1.0
To: Simon Riggs <simon@2ndquadrant.com>
CC: Fujii Masao <masao.fujii@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: bug of recovery?
References: 
 <CAHGQGwEEn13awaWZA-fMb76fNXASLLpqmUY8N-sK55ApZy-ErA@mail.gmail.com>
	<CA+U5nML8aK6iMpnaXf=vGYLCRkdqKUFJ6nTLTjEVpLj6oYYTRA@mail.gmail.com>
In-Reply-To: 
 <CA+U5nML8aK6iMpnaXf=vGYLCRkdqKUFJ6nTLTjEVpLj6oYYTRA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 26.09.2011 21:06, Simon Riggs wrote:
> 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.

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