Re: recovery getting interrupted is not so unusual as it used to be

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: recovery getting interrupted is not so unusual as it used to be
Дата
Msg-id A9087FC5-2F40-4CD2-8302-6B5AFED0FD4F@phlo.org
обсуждение исходный текст
Ответ на Re: recovery getting interrupted is not so unusual as it used to be  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: recovery getting interrupted is not so unusual as it used to be  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: including PID or backend ID in relpath of temp rels
Следующее
От: Robert Haas
Дата:
Сообщение: Re: recovery getting interrupted is not so unusual as it used to be