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

Re: bug of recovery?

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug of recovery?
Date: 2011-09-30 01:09:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Sep 29, 2011 at 11:12 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Sep29, 2011, at 13:49 , Simon Riggs wrote:
>> This worries me slightly now though because the patch makes us PANIC
>> in a place we didn't used to and once we do that we cannot restart the
>> server at all. Are we sure we want that? It's certainly a great way to
>> shake down errors in other code...
> The patch only introduces a new PANIC condition during archive recovery,
> though. Crash recovery is unaffected, except that we no longer create
> restart points before we reach consistency.
> Also, if we hit an invalid page reference after reaching consistency,
> the cause is probably either a bug in our recovery code, or (quite unlikely)
> a corrupted WAL that passed the CRC check. In both cases, the likelyhood
> of data-corruption seems high, so PANICing seems like the right thing to do.

Fair enough.

We might be able to use FATAL or ERROR instead of PANIC because they
also cause all processes to exit when the startup process emits them.
For example, we now use FATAL to stop the server in recovery mode
when recovery is about to end before we've reached a consistent state.


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Kyotaro HORIGUCHIDate: 2011-09-30 02:24:43
Subject: Re: [REVIEW] pg_last_xact_insert_timestamp
Previous:From: AlexanderDate: 2011-09-30 00:54:22
Subject: Re: REVIEW proposal: a validator for configuration files

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