Message-ID: <4BAA060A.2020000@enterprisedb.com>
Date: Wed, 24 Mar 2010 14:31:06 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Fujii Masao <masao.fujii@gmail.com>
CC: Simon Riggs <simon@2ndquadrant.com>, Aidan Van Dyk <aidan@highrise.ca>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server 	continuously
	retry restoring the next WAL
References: <3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com>	
	<20100211140118.GB14128@oak.highrise.ca>	
	<4B74118C.30704@enterprisedb.com>	
	<20100211144204.GC14128@oak.highrise.ca>	
	<4B743E7D.5070603@enterprisedb.com>	
	<3f0b79eb1002180337t1fab1395ve3491256672af15f@mail.gmail.com>	
	<4BA0B079.3050301@enterprisedb.com>	
	<3f0b79eb1003180727g7877743eq81274e014fe70a49@mail.gmail.com>	
	<1268988724.3556.3.camel@ebony> <4BA361E4.7020309@enterprisedb.com>
	<3f0b79eb1003230017v16f4ecbeyc20e75beeffe8f1c@mail.gmail.com>
In-Reply-To: <3f0b79eb1003230017v16f4ecbeyc20e75beeffe8f1c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Fujii Masao wrote:
> But in the current (v8.4 or before) behavior, recovery ends normally
> when an invalid record is found in an archived WAL file. Otherwise,
> the server would never be able to start normal processing when there
> is a corrupted archived file for some reasons. So, that invalid record
> should not be treated as a PANIC if the server is not in standby mode
> or the trigger file has been created. Thought?

Hmm, true, this changes behavior over previous releases. I tend to think
that it's always an error if there's a corrupt file in the archive,
though, and PANIC is appropriate. If the administrator wants to start up
the database anyway, he can remove the corrupt file from the archive and
place it directly in pg_xlog instead.

> When I tested the patch, the following PANIC error was thrown in the
> normal archive recovery. This seems to derive from the above change.
> The detail error sequence:
> 1. In ReadRecord(), emode was set to PANIC after 00000001000000000000000B
>    was read.
> 2. 00000001000000000000000C including the contrecord tried to be read
>    by using the emode (= PANIC). But since 00000001000000000000000C did
>    not exist, PANIC error was thrown.
> 
> -----------------
> LOG:  restored log file "00000001000000000000000B" from archive
> cp: cannot stat `../data.arh/00000001000000000000000C': No such file
> or directory
> PANIC:  could not open file "pg_xlog/00000001000000000000000C" (log
> file 0, segment 12): No such file or directory
> LOG:  startup process (PID 17204) was terminated by signal 6: Aborted
> LOG:  terminating any other active server processes
> -----------------

Thanks. That's easily fixable (applies over the previous patch):

--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -3773,7 +3773,7 @@ retry:
                pagelsn.xrecoff = 0;
            }
            /* Wait for the next page to become available */
-           if (!XLogPageRead(&pagelsn, emode, false, false))
+           if (!XLogPageRead(&pagelsn, emode_arg, false, false))
                return NULL;

            /* Check that the continuation record looks valid */

Perhaps the emode/emode_arg convention is a bit hard to read.

I'll go through the patch myself once more, and commit later today or
tomorrow if now new issues crop up.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com