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

Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date: 2010-03-24 23:23:01
Message-ID: 1269472981.8481.8946.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-docspgsql-hackers
On Wed, 2010-03-24 at 14:31 +0200, Heikki Linnakangas wrote:
> 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.

I don't agree with changing the behaviour from previous releases.

PANICing won't change the situation, so it just destroys server
availability. If we had 1 master and 42 slaves then this behaviour would
take down almost the whole server farm at once. Very uncool.

You might have reason to prevent the server starting up at that point,
when in standby mode, but that is not a reason to PANIC. We don't really
want all of the standbys thinking they can be the master all at once
either. Better to throw a serious ERROR and have the server still up and
available for reads.

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-docs by date

Next:From: Fujii MasaoDate: 2010-03-25 02:08:06
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Fujii MasaoDate: 2010-03-24 13:36:33
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-03-25 02:08:06
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Andrew DunstanDate: 2010-03-24 22:29:18
Subject: Re: xmlconcat (was 9.0 release notes done)

pgsql-committers by date

Next:From: User ItagakiDate: 2010-03-25 01:18:22
Subject: pgstatsinfo - pg_statsinfo: Fix to comapre csvlog filenames in their
Previous:From: Simon RiggsDate: 2010-03-24 21:41:57
Subject: pgsql: Additional thoughts on WALSender cpu reduction.

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