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 по дате отправления: