Re: recovery getting interrupted is not so unusual as it used to be - Mailing list pgsql-hackers

From Robert Haas
Subject Re: recovery getting interrupted is not so unusual as it used to be
Date
Msg-id AANLkTilNBFMwZIwlWl-JFM97Mvl5830ECLmoQp3BvKvz@mail.gmail.com
Whole thread Raw
In response to Re: recovery getting interrupted is not so unusual as it used to be  (Florian Pflug <fgp@phlo.org>)
Responses Re: recovery getting interrupted is not so unusual as it used to be  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug <fgp@phlo.org> wrote:
>> Oh.  Well, if that's the case, then I guess I lean toward applying the
>> patch as-is.  Then there's no need for the caveat "and without manual
>> intervention".
>
> That still leaves the messages awfully ambiguous concerning the cause (data corruption) and the effect (crash during
recovery).
>
> How about
> "If this has occurred more than once, it is probably caused by corrupt data and you have to use the latest backup for
recovery"
> for the crash recovery case and
> "If this has occurred more than once, it is probably caused by corrupt data and you have to choose an earlier
recoverytarget" 
> for the PITR case.
>
> I don't see why currently only the PITR-case includes the "more than once" clause. Its probably supposed to prevent
unnecessarilyalarming the user if the "crash" was in fact a stray SIGKILL or an out-of-memory condition, which seems
equallylikely in both cases. 

I've applied the patch for now - we can fix the wording of the other
messages with a follow-on patch if we agree on what they should say.
I don't like the use of the phrase "you have to", particularly...  I
would tend to leave the archive recovery message alone and change the
crash recovery message to be more like it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: [RFC] A tackle to the leaky VIEWs for RLS
Next
From: Michael Paquier
Date:
Subject: Re: current value support