Re: Idea for improving buildfarm robustness

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Idea for improving buildfarm robustness
Дата
Msg-id 707.1443554317@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Idea for improving buildfarm robustness  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/29/2015 02:48 PM, Tom Lane wrote:
>> Also, perhaps we'd only enable this behavior in --enable-cassert builds,
>> to avoid any risk of a postmaster incorrectly choosing to suicide in a
>> production scenario.  Or maybe that's overly conservative.

> Not every buildfarm member uses cassert, so I'm not sure that's the best 
> way to go. axolotl doesn't, and it's one of those that regularly has 
> speed problems. Maybe a not-very-well-publicized GUC, or an environment 
> setting? Or maybe just enable this anyway. If the data directory is gone 
> what's the point in keeping the postmaster around? Shutting it down 
> doesn't seem likely to cause any damage.

The only argument I can see against just turning it on all the time is
the possibility of false positives.  I mentioned ENFILE and EPERM as
foreseeable false-positive conditions, and I'm worried that there might be
others.  It might be good if we have a small list of specific errnos that
cause us to conclude we should die, rather than a small list that cause us
not to.  But as long as we're reasonably confident that we're seeing an
error that means somebody deleted pg_control, I think abandoning ship
is just fine.
        regards, tom lane



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Idea for improving buildfarm robustness
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Idea for improving buildfarm robustness