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

From Florian Pflug
Subject Re: recovery getting interrupted is not so unusual as it used to be
Date
Msg-id A9087FC5-2F40-4CD2-8302-6B5AFED0FD4F@phlo.org
Whole thread Raw
In response to Re: recovery getting interrupted is not so unusual as it used to be  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: recovery getting interrupted is not so unusual as it used to be  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Jun 3, 2010, at 5:25 , Robert Haas wrote:
> 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
forrecovery" 
>> 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.

Since a loose log of this shed gave me quite a bump on my forehead once, one last attempt at fixing it.

I've tried to keep this as similar as possible to the existing message while making it less ambiguous about cause and
effect.

"If this has occurred more than once corrupt data might be the cause and you might need to choose an earlier recovery
target".
and
"If this has occurred more than once corrupt data might be the cause and you might need to restore from backup".

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: including PID or backend ID in relpath of temp rels
Next
From: Robert Haas
Date:
Subject: Re: recovery getting interrupted is not so unusual as it used to be