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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-docs pgsql-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

Browse pgsql-committers by date

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

Browse pgsql-docs by date

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

Browse pgsql-hackers by date

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