On Wed, Mar 24, 2010 at 9:31 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > 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.
Okay. > 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 */ Seems correct. > sources &= ~failedSources; > failedSources |= readSource; The above lines in XLogPageRead() seem not to be required in normal recovery case (i.e., standby_mode = off). So how about the attached patch? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
failedSource_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
