Re: Missing pg_control crashes postmaster

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: Missing pg_control crashes postmaster
Дата
Msg-id be2917f0-e01b-b07d-73a2-447f088bfdd4@pgmasters.net
обсуждение исходный текст
Ответ на Re: Missing pg_control crashes postmaster  (Andres Freund <andres@anarazel.de>)
Ответы Re: Missing pg_control crashes postmaster  (Andres Freund <andres@anarazel.de>)
Re: Missing pg_control crashes postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 7/25/18 10:37 AM, Andres Freund wrote:
> On July 25, 2018 7:18:30 AM PDT, David Steele <david@pgmasters.net> wrote:
>>
>> It seems like an easy win if we can find a safe way to do it, though I
>> admit that this is only a benefit in corner cases.
> 
> What would we win here? Which scenario that's not contrived would be less bad due to the proposed change.  This seems
complexityfor it's own sake.
 

I think it's worth preserving pg_control even in the case where there is 
other damage to the cluster.  The alternative in this case (if no backup 
exists) is to run pg_resetwal which means data since the last checkpoint 
will not be written out causing even more data loss.  I have run 
clusters with checkpoint_timeout = 60m so data loss in this case is a 
real concern.

I favor the contrived scenario that helps preserve the current cluster 
instead of a hypothetical newly init'd one.  I also don't think that 
users deleting files out of a cluster is all that contrived.

Adding O_CREATE to open() doesn't seem too complex to me.  I'm not 
really in favor of the renaming idea, but I'm not against it either if 
it gets me a copy of the pg_control file.

Regards,
-- 
-David
david@pgmasters.net


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Missing pg_control crashes postmaster
Следующее
От: David Fetter
Дата:
Сообщение: Re: How can we submit code patches that implement our (pending)patents?